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.
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 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.
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 write some app which analyze Instagram and Twitter posts (post serves in separate tables) and I load comments and likes too. So, it's good to use they id's as my primary key, or is better to create my id's which will not be related to third-party id.
Create your own ids in your database. In general you want these properties to be true about your primary keys:
Unique. This one the database management system will enforce for you.
Unrelated to the data they identify. This means that you shouldn't be able to calculate the primary key to any row based on the info in the row. For example, first name+last name would be a bad primary key for a People table, and credit card number would be a bad primary key for BillingInfo table.
By using the id generated by a third party service as your PK, you are unnecessarily coupling your database with their service.
Instead, there is a common pattern of using an altId column to store an extra id. You could even name the column better by calling it twitterId or something similar.
Apart from uniqueness and minimality three sensible criteria for deciding on keys are stability, simplicity and familiarity.
Above all, there is the business requirement: the need to represent the external reality with some acceptable degree of accuracy. If your database is intended to represent accurately things sourced from some given domain then you will need an identifier also sourced from that domain.
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 7 years ago.
Improve this question
Theoretical:
I've been tasked with building a database to contain guidelines for manufacturing purposes. The guidelines to be returned are based on 42 input values and are all specific to the particular combination of inputs.
I plan on indexing all of these columns and realize that it will be resource intensive if I have to rebuild or re-index.
What design approaches have I not considered? What potential problems exist with the approach of creating a unique constraint on 42 columns? Does anyone have any experience with this sort of a design or any insights?
Thanks for any help!
A good reason for not doing it is that SQL Server doesn't support it:
Up to 32 columns can be combined into a single composite index key.
(documentation here).
It seems unlikely that you really need a single composite index with 42 columns. But, you can't have one even if that were desirable.
Put index only on columns which will be searched/sorted.
Add simple autoincrement index.