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.
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 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 5 years ago.
Improve this question
My question is that I want to learn nodejs/express, and make a super simple web project. It would be a database with tables : users, video_games, categories.
The web site will just show list of games (just an example).
In this typical case, what would be more efficient : Mysql or MongoDB (SQL or NoSql) ?
In this particular case were you want to show only list ( you don't want to actual store videos, doc, texy, etc..) SQL database will be a good choice.
Another reason to use SQL database is that your data is relational ( I am assuming that the data i.e video_games, category...etc are linked to users) were SQL database suits more.
You should go to nosql database only when there is to relationship between your data ( well this is not the only case, but for beginners were your aim is to simply pick the right database this suffice)
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
I am about to develop a small cms\forum. Multiple customers are going to have there own access where the customers can communicate white them.
What is best practices- to make separate SQL db to each customer's cms data or one big to contain all the customers data?
As I cannot comment, so I can only type here.
It is strange that you would like to have separate database for each customer and it seems impossible to manage multiple db for just one purpose or function. For example, how could you identify which db belong to which customer? Also, do you expect to have many resource to allocate to each customer? a db simply waste if the customer is not active.
So, I suggest you to use one db to manage all the customers data which is normal solution.
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
Let's say I have a User model and a Favorite model. I want to know how many favorites a user has.
I see that you can accomplish this in two ways.
Atomically increment a counter attribute on the user model when a favorite is created. Access using user_instance.favorite_count
Query the favorite count for the user: user_instance.favorite_set.count()
I would imagine that as the DB grows, counting becomes more expensive.
Which implementation is more scalable?
I smell some premature optimization here. Databases are extremely good at counting things. Unless you have measured and are seeing some identifiable slowness, you should not attempt to denormalize: it is difficult to get right and always at risk of getting out of sync. Go with the query; and don't forget you can use aggregation to query the counts for a queryset of users at one time.