I have a newb database question. I have a list of publications, and I want to create a database. I had been thinking I would do:
UID, Author, URL, Title, Publication, start page, end page, volume, year
for the columns in my database,but then I saw that some publications have numerous authors, and I'm not sure how to handle that. What should I do?
The normal action would be to create a separate table for the authors and then create a separate table, where you store the primary keys for author and books, take a look at the following example (Fourth Normal Form):
Database Normalization
Related
I have this scenario where I have three entities Book, Review, comment and have the following tables:
Books (Id, ReviewCounts)
BookTranslations (BookId, LanguageId, IsDefault, Title, Description)
Reviews (Id, BookId, CommentCounts)
ReviewTranslations (ReviewId, LanguageId, IsDefault, Content)
Comments (Id, ReviewId, Content)
Now, I want to add two other entities to the design, Vote and Report. The vote entity represent a vote the user do on all of the previous three entities, Book, Comment, Review. And the report, where the user should be able to report fake Books, inaccurate Reviews, hate and illegal Comments and fake User profiles.
The problem is, I need now to add three tables for the vote BookVotes,CommentVotes, and ReviewVotes. And four different tables for the report UserProfileReports, BookReports, ReviewReports, CommentReports.
Now, I think about adding one base table so to speak, called Entities, and another table EntityTypes, where EntityTypes contains data like "Book,Review,Comment". And the same primary key will be in Entity and Review or Entity and Book and so on. This way I will solve the vote issue, but not the report because the user can report a user profile which is a User entity. It doesn't make any sense to add the User entity to the list of the three aforementioned entities and "derive" it from the Entities "base" table too.
To be honest, I don't think the usage of one "base" table Entities make sense either, because conceptually the book, review, and comment are three totally different entities.
So, my question is, should or shouldn't I go with the "base" table solution, and if so, how should I solve the report problem?
I would NOT go with the single "base" table idea. Since a single vote can only be about either a book or a comment or a review, but not about multiple items, it makes more sense to me to keep them in separate tables. Same for reports.
Databases with lots of small tables tend to perform better than databases with just a few big tables, so unless there's a modelling reason to combine the entities, I wouldn't do it.
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.
I'm creating this little Access DB, for the HR department to store all data related to all the training sessions that the company organizes for all the employees.
So, I have a Training Session table with information like date, subject, place, observations, trainer, etc, and the unique ID number.
Then there's the Personnel table, with employer ID (which is also the unique table number), names and working department.
So, after that I need another table that keeps a record of all the attendants of each training session. And here's the question, should I use a table for that in the first place? Does it have to be one table for each training session to store the attendants?
I've used excel for quite some time now, but I'm very new to Access and databases (even small ones like this). Any information will be highly appreciated.
Thanks in advance!
It should be one table for persons, one table for trainings, and one for participation/attendance, to minimize (or best: avoid) repetition. Your tables should use primary and foreign keys, so that there are one-to-many relationships between trainings and attendances as well as people and attendances (the attendances table would then have a column referring to the person who attended, and another column referring to the training session).
Google "database normalization" for more detail and variations of that principle (https://en.wikipedia.org/wiki/Database_normalization).
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.
I am getting in backend of Typo3 a list of the entries from database table "Books" via SysFolder. I can make new books, edit books etc..
I have also a database table "Extrainformation" where I would like that will come the extra information about the book. In table "Extrainformation" there is a key "Book_id" as a connector between the tables.
What I am trying to get is that when I make a new record via this SysFolder I would like to get some of the fields saved in the different table.
Like when I have input fields:
Bookname
Book description
Book Publishdate
Extrafield1
Extrafield2
I would like that infos about Bookname, Book description and Book Publishdate would be saved in the table "Books" and infos about Extrafield1 and Extrafield2 would be saved in "Extrainformation" table. (And then when I edit a book it should bring the data in to the form from these two tables)
Has someone made something like this before? Is there some easy way to combine databaseinformation from multiple tables via SysFolder? When there is no "easy" way, does someone know where would it be possible to "hack" (saving data in database / getting data from database) so that it would be possible to merge the data in one form.
You are looking for "Inline relational record editing" IRRE.
BTW, there is nothing special about folders in the pagetree. Technically there is no difference to "normal" pages, except that they will not be rendered in frontend.