I'm designing a database and I'm looking for the best way to format the tables. The users can check in and check out boxes, tapes, CDs, and other types of media. I want a history of who has checked out what and at what times. Here is a simplified version of my current schema:
User(id, first_name, last_name)
Box(id, description)
Tape(id, description)
CD(id, title)
check_in(id, in_date, out_date, fk_user)
check_in_history(id, fk_checkin, media_type)
I have a table for the User and the different types of media. The check-ins are also stored in a separate table. For the check-in history I have the foreign key of the check-in table along with a field for the media type so I can determine which table, and thus which type of media is being referred to by the check-in. Still, this seems like a kludge and feels inefficient. Is there a better way to design this database?
Edit: The different types of media have a lot of different properties that I left out for simplicity so they can't be in the same table.
I would do it this way; Have one table for media with id,type,description, title.
The check_in table needs to have a link to the media table. Thus the check_in links the user and the media.
There is no reason for a history table. The check_in table will have a history of all loans.
Related
How to design one to one database table?
I have a report that gets data from users. But report includes multiple type of records.
Report includes following information:
Customer information (name, age, city, ...)
Company information (name, address, coutry, year, ...)
Device information (devname, code, serialnumber,...)
Approve information (who_approved, date, ..)
and more information.
So I have a report table. But should create only one report table and add all columns in this table?
Or should I create a Reports table and CustomerInformation, CompanyInformation, DeviceInformation, ApproveInformation and one to one relationships?
First of all, you should know if you are going with MYSQL or MongoDB.
In MYSQL, it is not a good approach to use clustered table. While, in MongoDB, using clustered table is always an option.
Anyways, normalizing the database is the best approach. Which means, you should make more tables if possible but avoid data redundancy
my user need to bookmark the articles, videos, pictures posted by the others.
now I have a user table, an article table, a video table.
and I come up with two way to store the bookmark data..
first, I can create three one-to-many table.
the second way is only create a table and add a category column on it..
with the first approach, I can store foreign keys to associate with the articles and video table. witch is easier for the orm system
and the second way only need a table, but can't store the relationship..
so. which one should I choose,or Is better???
the third way is something like.
I have worked with tables that employ both types of relationships. For ease of use, I do not prefer the second method. There is another method you may wish to try, which would be (sorry, no picture):
USER
UserId
USER_BOOKMARK
UserBookmarkId
UserId
BookmarkAssetId
USER_BOOKMARK_ASSET
UserBookmarkAssetId
UserBookmarkId
AssetType (Title, href, image, caption, tooltip, etc)
AssetStringValue (nullable)
AssetNumberValue(nullable)
AssetByteArray (nullable)
You would get a bookmark like:
SELECT * AS UserBookmarkLinks
FROM USER_BOOKMARKS ub
INNER JOIN USER_BOOKMARK_ASSETS uba
ON ub.UserBookmarkId = uba.UserBookmarkId
WHERE ub.UserId = 12345
AND uba.AssetType = "Link"
From there you may have BOOKMARK_TYPE_ASSETS which tells you what assets are included with each type and which field in USER_BOOKMARK_ASSETS it uses. This is a little more involved with tables, but a lot closer to normalized.
Is it better to create tables that store a lot of data that are related to an entity (User for example) or many tables to store said data?
For example:
User Table
Name
Email
Subscription Id
Email Notifications
Permissions
Or
User Table
Name
Email
Subscription Table
User ID
Subscription ID
Notification Table
User ID
Receives?
... etc
Please consider code in this as well, or I would have posted to ServerVault.
From a relational design standpoint what is important is the normal form you're aiming for. In general, if the "column" would require multiple values (subscription_id1, subscription_id2, etc) then it is a repeating group, and that would indicate to you that it needs to be moved to a related table. You've provided very general table and column notes, but taking a cue from the fact that you named "Email Notifications" and "Permissions" with plurals, I'm going to assume that those require related tables.
I'm designing a database that has a couple of tables; FAQ's, Bulletins, and Attachments. Bulletins and FAQ's could have an attachment associated with them, so my initial thought was to create a joining table with the two primary keys as a composite key:
Bulletin
--------
BulletinID
Subject
Description
Notes
Attachment
-----------
AttachmentID
FileName
FilePath
etc.
Joining table:
BulletinAttachments
-------------------
BulletinID
AttachmentID
As I design this, I also thought, what if other entities are introduced later (say Newsletter, Email, etc.) that need Attachments as well. I would have to create a joining table for each of these entities. Not awful, but it made me think, what if I got rid of the joining tables and put an AttachmentType in the Attachment table and then assigned the type accordingly:
AttachmentType
--------------
AttachmentTypeID
AttachmentType
Description
The data in that table would be:
1-Bulletin
2-FAQ
3-Newsletter
4-Email
Then the Attachment table would hold the AttachmentTypeID to identify it:
Attachments
-----------
AttachmentID
AttachmentTypeID
FileName
FilePath
etc.
So my question is, for performance wise (using SQL 2008 R2), is there a better choice between the two? Is there a better way to design this? My concern with using individual joining tables is that we may have more entities come along and to accommodate Attachments, we would have to create a joining table and on our front-end software, we would have to write logic for it whereas the AttachmentTypeID would allow the front-end to insert a new AttachmentType and no db interaction would be needed.
Your second solution doesn't have a way to link the attachment to the item, just what kind of item it is.
Even if it did (ie: an itemID), what you would create would be a violation of 4th Normal form - ie: a multivalued dependency.
Stick with your first plan, but consider whether Bulletins are fundamentally different to Newsletters, Emails, FAQs, etc in your application. If you do need a new table for Newsletters, add a new table for NewsletterAttachments.
Also consider, are you going to share attachments between different items, or types of item?
I am totally agree with podiluska. you need to create separate table for each type of attachment otherwise you cant map itemid with attachment and you will face a problem of joining table for different type of attachment . also if you make separate table for each type of attachment then performance will be faster .
I have a user table which has about 50-ish pieces of data. Some of it is Religion, political party, Ethnicity, City, Favorite movies, etc. Each of these items are lookup values from either: Their own lookup table OR I have a common lookup table for the small items like gender, sex preference, etc. Even favorite movie is from a movie lookup table.
The question is i assume in the member table all these will be stored as IDs and not text? So first Q:
1) Should they or should they not have FKs to the lookup tables?
2) If we store IDs then to get the actual answer text like Id 6 in city table = new york, Id 10 in nationality table = American etc. for the actual output on the page ,how will it be done? Do we need to Select from each lookup table in the read mode to output the text value? This scares me because out of the 50 pieces of data about 40 of them are lookup based, so that means 40 different select on 40 tables on page read mode and again on edit mode for the user to edit the values.
How is this implemented in real world sites with detailed user profiles? (I have search and analytics on each value so I need to ID them)
Depends on the scope, but this sounds like a sync process - setup a weekly/daily/hourly process to resync extended user information into a master table with a foreign key to the "user"-related table (username, password, email, update stamps, etc...).
What you've described is the big tradeoff between normalized DB design and more of a flat-table design: the queries are a lot more complicated with the normalized design, which is sounds like you have.
I'd think that you'd be reading from the table a lot more than you'd be writing to it? (How often does a person's religion, gender, city, etc. change?) In this case, (only) if you're running into performance issues on the read end, you might maintain two representations of the table: one extensible, normalized one like you have, and a plain-text, flat version that's fast and piece of cake to query and read. When you update the record in the normalized one, you update the record in the flat one.