Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
For example, you have tables Users and Groups; a user can be member of many groups, and a group has many users.
So how would you name the table that connects them?
Should it be user_groups or group_members ?
Personally, I think the latter is better.
Though it depends. If I want to know the groups of a user, I think the former is better. If I want to know the members of a certain group, I think the latter is better. However, I think it's not right to create both table since they are the same.
See first reply from What should I name a table that maps two tables together?
Your question can be considered as duplicate, because already exist one with a good answer there.
And my personal answer for your question, I prefer to use a prefix for all many-to-many tables, example : MapGroupUser, where "Map" is the prefix. So, all tables of this particular type will be different from the others
I would like the table name to help me identify the tables from which it holds the data. Although group_members seems more logical, I would prefer users_groups as it clearly mentions the tables from which it holds data.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I want to which is, in your opinion, the best practice for name SQL columns.
Example: Let's say that i have two columns name referenceTransactionId and source
now there is another way to write this like refTxnId and src
which one is the better way and why? Is it because of the memory usage or because of the readability?
Although this is a matter of opinion, I am going to answer anyway. If you are going to design a new database, write out all the names completely. Why?
The name is unambiguous. You'll notice that sites such as Wikipedia spell out complete names, as do standards such as time zones ("America/New_York").
Using a standard like the complete name means that users don't have to "think" about what the column might be called.
Nowadays, people type much faster than they used to. For those that don't, type ahead and menus provide assistance.
Primary keys and foreign keys, to the extent possible, should have the same name. So, I suspect that referenceTransactionId should simply be transactionId if it is referencing the Transactions table.
This comes from the "friction" of using multiple databases and having to figure out what a column name is.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I work for a firm with a relational database. Some of my colleagues once told me that storing data directly on relationships (and not on entities) was a bad pratice. I can't remember why. Can you help me with that ? Do you agree ? What are the risks ?
Many thanks !
No, this is not a bad practice. In fact, "relationships" are often entities themselves. For instance, an "order" might relate a "person" and "store". It would also naturally have other information such as when the purchase happened, the payment amount, the total amount, and so on.
In general, when I create tables in SQL, I include information such as:
createdAt -- the date/time the row was created
createdBy -- who created the row
createdOn -- the system where the row was created
This would be true on all tables, even those representing many-to-many relationships.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm working on a project and I usually use the person's ID as a primary key to identify the person. But right now I'm working on something much more formal and serious then what I've been working on... (School DB) Is it good practice to use the person's/student's ID card instead of having another field (ID) auto generated/sequence as a PK.
It is a bad idea, for one simple reason: security.
You are better off designing your databases to have internal ids for all entities. The person's id would then be an attribute on the records, rather than a primary key. This allows you, for instance, to encrypt the id (and other sensitive information). If someone gets a hold of a print-out of some data, you don't have to worry that they are seeing personal information.
In the United States, this design is helped by the fact that social security numbers -- the closest thing we have to a national id -- were specifically designed not to be national id numbers. Apart from the issue of fraud, the approximately one billion numbers will run out one day.
I look after a similar student database and we use student ids as PK.
It helps us because students are aware of their IDs and if they have any issues they can come to us and quote their ID for us to resolve the issue. It certainly makes it easier than trudging through a load of John Smiths.
The down side I have found is that we do export data to programs such as excel and alot of the IDs have leading zeros which if you are not careful will be removed.
It is entirely up to you, but in my opinion I would use them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to make website for a school and because of that I need a suggestion. I'm trying to make a schedule table for each teacher would it be good to set them in one table or in different tables for each teacher(Note: Teachers can change the schedule from the site.)? The schedule table looks like this but in order to include the schedule of all teachers I wanted to add the ID column too.
And the second question about chatting. In order to add the chatting function to my site, I've opened a new table with name Chats. So the question is would it be good to open different tables for the chats or it would be good if I modify the Chats table each time new chatting called?
As a rule of thumb, if you have the same type of data, it should almost always(*) be stored in the same table.
So to answer your question more directly: you want to put all teacher's schedules in a single table. And then have a column in that table that identifies each row as being part of a specific teacher's schedule.
Again, the answer applies to the second question. All chats should go into a single Chats table. You would use a column to identify a chat (message) as being part of a conversation, as well as the participants.
(*) To further expand on the almost always above. The reason I said almost always and not just always is that there may be some cases when having two, or more, tables contain the same type of data would be a good idea. For instance, in the schedules example. You may want to keep all teacher's schedules data in the Schedules table but periodically move data older than a year out of that table into an ArchivedSchedules table. This second table may have pretty much the same structure as the Schedules table but separating the data this way would make sense because it would improve access performance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
how does one know when to use an array for foreign keys vs a junction table? (which will achieve better performance in which scenarios) IE if i know i only have the 12 months as my foreign key i would assume that the array would perform better. Does anyone know how to justify when one would perform better than the other? are there things to look for?
like if the many to many relationship exists where each one only has typically 5 foreign keys. what about 10. how about 1000, etc. when do you make the call to stop using a junction table and use an array?
I am not looking for opionions. I am looking for ways in which to determine how to measure or make a call for what is the better performance choice.
If you have a many-to-many table, you should always use a junction table. If you have a one to many relationship you should have parent child tables. What you shoudl virtually never have is a table with fields like: Phone1, Phone2, Phone3.