I'm creating a system whereby it allows employees to log in day they work (eg, Monday/Tuesday...etc) and their time.
I have the "Employee" tables and a "Timesheet" table. Should the relationship be one to one or many to many or others?
Thanks for the help.
Related
I have merged the existing database into an Identity database (created by the built-in MVC template with Individual User Accounts). Below you'll see a partial diagram.
I have added extra properties to the AspNetUsers table via code first approach. All CRUD actions for this table are performed via the ApplicationUserManager. My next planned step is to create an Entity Framework model using the database first approach and select only the non Identity tables. I'm having issues grasping the proper way to deal with the AspNetUsers and People table.
The People table will include users and non users. Most AspNetUsers will also have People entries, but not all People entries will be AspNetUsers. The People table will have similar fields, not yet added, as the AspNetUser (Address, City, State, etc...). Obviously this will create duplicate data. What's a "best practice" way to do deal with this? I considered adding an address table between them, but then I don't know how that would work with the ApplicationUserManager as it's only expecting the tables it created.
Im making an ERD now for medicine care.
I have an issue with 2 entities:
Patient and caregiver.
The caregiver is a person that helps for the patient and can do features on the application for the patient.
For now I choose that the patient is a separate user from the caregiver.
If its like that,I need to do a seperate entities for the caregiver and for the patient. When I do this , there is an overload on the ERD because the 2 entities can do the same thing on the system so they have the same connections to other entities.
In addition , they have just one attribute that is different between them and this is the diagnosis of the patient.
What to do?
I would suggest looking into adding the caregiver as a sub class if all the rows are the same apart from one. But having them both as separate entities wouldnt be an overload on the database as long as you add primary/foreign keys correctly. Have you got a current ERD i can look at?
I am currently developing a new database / web application for our school. I will need to supply a little bit of background information to make my question a little more relatable.
There are many different user types that will access this application each needing to access different parts of the application with different permissions for each “zone” they may be able to access.
For example:
A student can login and access there information and update their details as well as download copies of their reports (so they can only see their information)
A teacher can login and access there information and all the students they teach
A manager can login and access there information and all the teachers and students they manage
There are then a bunch of other login types however for this question they are not really important as they are all technically just more users which do not have or require their own table for extra information.
I have for the most part decided on a structure that I am happy with, however I keep changing my mind on how I think the following is best done.
I have a user table (User_T) where all the relevant user information is stored, (username, password, etc.)
However I also have separate tables for some of the user types (EG, Student, Staff, ETC), this is necessary because a student needs to have different information stored than a staff member.
Here is where my problem lies, all of the users will have some of the same basic fields (First name, Last name, Birthdate, Gender, etc.).
Should I store these in the User_T table? Or in the individual tables?
If I store them all in the User_T table this makes it easier to have the application pull their information and allow them to update, on the down side when displaying student details for example, I will need to reference the User_T to get the students name etc.
I am currently in the mindset that the best option is to have the separate tables with all the fields and join them in a view User_V, with a field that indicates the origin of the data so that when an update is preformed it can be applied against the appropriate table.
Thoughts?
Sounds like there would be good separation by using the User_T table as the general "people" profile table and the other tables for the unique role specific data. User_T would store the more general info about the person and the ID in this table would be perhaps a Foreign Key called "person_id" in the other tables.
Going with this table schema would also depend on how often you might query this shared general data together. For example, if you plan to search a name or email without knowing the type/role (whether staff, student, etc), then it is good to have this general people information in the User_T table apart from the other information. If you knew the role/type, you could choose the corresponding table to search in and simply JOIN as needed for the User_T data. But if you don't separate your tables this way, then you are left with using a VIEW or UNION to allow you to search on only those general columns with a single query, which in my opinion is much more troublesome to optimize.
User_T table: id, first_name, last_name, email, gender, birthdate, role, ...
Students table: id, person_id, gpa, ...
Staff table: id, person_id, staff_type, hire_date, ...
I'm fairly new to Access.
I have a DB table that needs to be normalized. I have some information about a person. These people are authorized to grant access to areas at our work site. Every person may be authorized several times to manage different areas, and of course different people can be authorized to manage different areas. My first try at it was to include the authorization and the areas together, but I realized that I was really repeating the data that way. After doing some study I decided that the best way to do this was to create 4 tables
tblPerson, tblPermission, tblArea, tblArea_Permission
The tblArea_Permission is a join table for the many-to-many relationship between tblPermission and tblArea (this is something that I just learned about). I seemingly set up the table relationships OK on the relationship tab. I also use a query for adding the records to the join table. When I try to do this, with a query that is getting the records from the tables, I get "You cannot add or change a record because a related record is required in table XXX." This would seem to be impossible.
I decided that I could probably live with the DB not enforcing referential integrity and took that away and used a combined primary key for the two records because every person with permission will control an area in only one combination. That seemed to work, but then I noticed that the records would randomly change. I decided that the DB must be corrupt. Parts of the DB seem to be working correctly, so I started with a new database and imported the tables and one form, then started to rebuild the new tables as described above. I got the same error.
Any help would be greatly appreciated. I've read through some different books, and used google, but nothing addresses this.
If a person is authorised to manage an area, you need a persons_area table:
PersonID ) Primary key
AreaID )
Which shows which areas the person can manage. I am not sure where the permissions table is coming from.
You will then not be able to add a record to person_areas table unless you have an ID in the area table and an ID in the persons table. If either of these IDs are missing, you will get the error above.
If you want more relevant comments on your DB design, you will need to post schemas.
I am planning to create a website using ASP.NET and SQL Server. However, my plan for the database design leaves me wondering if there is a better way.
The website will serve as a repository of information for various users. I figure I would have two databases, a Membership and Profile database.
The profile database would contain user data for all users, where each user may have ~20 tables. I would create the tables when the user account is created and generate a key used to name the tables. The tables are not directly related.
For Example a set of tables for two different users could look like:
User1 Tables - TransactionTable_Key1, AssetTable_Key1, ResearchTable_Key1 ....;
User2 Tables - TransactionTable_Key2, AssetTable_Key2, ResearchTable_Key2 ....;
The Key1, Key2 etc.. values would be retrieved based on the MembershipID data when the account was created. This could result in a very large number of tables over time. I'm not sure if this will limit scalability by setting up the database in this way. Any recommendations?
Edit: I should mention that some of these tables would contain 20k+ rows.
Realistically it sounds like you only really need one database for this.
From the way you worded your question, it sounds like you're trying to dynamically create tables for users as they create accounts. I wouldn't recommend this method.
What you want to do is create a master table that contains a primary key for each individual user. I'm assuming this is the Membership table. Then create the ~20 tables that you need for the profiles of these members. Every record, no matter the number of users that you have, will go into these tables. These 20 tables would need to have a foreign key pointing to the unique identifier of the Membership table.
When you want to query a Member for their user information, just select from the tables where the membership table's primary Id matches the foreign key in the profile tables.
This would result in only a few tables in the end and is easily maintainable and follows better database design.
Your ORM layer (EF, LINQ, DAL code) will hate having to deal with one set of tables per tenant. It is much better to have either one set of tables for all tenant in a single database, or a separate database per tenant. The later is only better if schema upgrade has to be vetted by tenant (like Salesforce.com has). If you can afford to upgrade all tenant to a new schema at once then there is no reason for database per tenant.
When you design a schema that hold multiple tenant the important things to remember are
don't use heaps, all tables must be clustered index
add the tenant ID as the leftmost key to every clustered
add the tenant ID as the leftmost key to every non-clustered index too
add the Left.tenantID = right.tenantID predicate to every join
add the table.TenantID = #currentTenantID to every query
These are fairly simple rules and if you obey them (with no exceptions) you will get a perfect partitioning per tenant of every query (no query will ever ever scan rows in a range of a different tenant) so you eliminate contention between tenants. To be more through, you can disable lock escalation to make sure no tenant escalates to block every other tenant.
This design also lends itself to table partitioning and to sharing the database for scale-out.
You definitely don't want to create a set of tables for each user, and you would want these only in one database. Even with SQL Server 2008's large capacity for tables (note really total objects in database), it would quickly become unmanageable. Your best bet is to use 20 tables, and separate them via a column into user areas. You might consider partitioning the tables by this user value, but that should be tested for performance reasons too.
Yes, since the tables only contain id, key, and value, why not make one single table?
Have the columns:
id, user ID, key, value
Put an Index on the user ID field.
A key idea behind a relational database is that the table structure does not change. You create a solid set of tables, and these are the "bones" of your application.
Cheers,
Daniel
Neal,
The solution really depends on your requirement. If security and data access are concern and you have only a handful of users, you can set up a different db for each user with access for him set to only his/her database.
Other wise, what Daniel Williams suggested is a good alternative where you have one DB and tables laid out with a indexed column partitioning the users data rows.
It's hard to tell from the summary, but it looks like you are designing for dynamic attribution by user. This design approach is called EAV (Entity-Attribute-Value) and consists of a simple base collection key (UserID, SiteID, ProductID...) and then rows consisting of name/value pairs. In a more complex version, categories are sometimes added as "super columns" to the tuple/row and provide sub-groupings for a set of name/value pairs.
Designing in this way moves responsibility for data type integrity, relational integrity and tuple integrity to the application layer.
The risk with doing this in a relational system involves the breaking of the tuple or row into a set of rows. Updates, deletes, missing values and the definition of a tuple are no longer easily accessible through human interaction. As your application evolves and the definition of a tuple changes, it becomes almost impossible to tell if a name/value pair is missing because it's part of an earlier-version tuple or because it was unintentionally deleted. Ad-hoc research as well becomes harder to manage as business analysts must keep an understanding of the virtual structure either in their heads or in documentation provided.
If you are looking to implement an EAV model, I would suggest you look at a non-relational solution (nosql) like MongoDB or CouchDB. These stores allow a developer to save and retrieve "documents" or json-formatted messages that are essentially made up of a collection of name/value pairs and can look very much like a serialized object. The advantage here is that you can store dynamic attribution without breaking your tuple. You always know that you have a complete tuple because you can store and retrieve it as a single "blob" of information that can be serialized and deserialized at-will. You can also update single attributes within the tuple, if that's a concern.
MongoDB also provides some database-like features such as multiple-attribute indexes, a query engine that is robust in comparison to other similar non-relational offerings and a sharding solution that is much less trouble than trying to do it with MySQL.
I hope this helps.