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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm not a database expert, but I'm curious about auto-incrementing in SQL.
Is it efficient, a friend of mine, his opinions, he's not using auto-incrementing instead he's taking the last id every time he insert something. I'm in doubt whether to use his ideas, which I guess is less efficient or go with auto-incrementing provided by the database itself.
I would use auto-increment every time. It is, by far, the best way to ensure that you have unique values.
If you use the previous highest value, unless you are careful, there is a chance that the same value may be written twice - for example if when two instances of the application retrieve the same previous highest value, add one and insert the new row. (I have seen it happen..)
Both SQL Server and My SQL have built in the auto-increment functionality for a reason. You should only avoid them if you have a specific need for something else.
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 am deploying an application at one of our vendor. We have few special character that needs to be removed using a function. Vendor is really slow with any changes that we request.
I have access to one of the configuration table that we use to save configuration table.
I want to save a SQL function in the table column that I will fetch at run-time and will execute it.
I am not sure if its a good programming practice. Please suggest if this should not be used then why or is there any other way to do it?
Database is SQL Server. Suggest if it's a good programming practice.
A better practice would be to write your function in such a way that you don't have to change it every time a new special character pops up.
Instead of writing a function that filters out a predefined set of special characters, why don't you write a function that allows a predefined set of non-special characters? Then you should never have to change it.
you can use a Computed column in sql server, for me it's not a good practice depending on the scenario that you are trying to achieve but I think this might help you
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.
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.