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 8 years ago.
Improve this question
Right now, I am designing the database as you all know, primary keys are important factor in the database design.
I have dilemma in deciding the primary key between GUID, identity (Auto Increment) and a custom key for primary key, in which scenario should I use?
I am trying to database design for school. School has many branches in the different location and different cities. school have central database, they want to update every day at evening.
Please guide me? Thanks
In my opinion, the default choice is to use a 32-bit integer with auto-increment.
You might use GUID under specific scenarios that are covered in this QA: What are the best practices for using a GUID as a primary key, specifically regarding performance?
A custom key should only be used if you need to assign a specific key for some reason based on your design or based on business requirements.
Edit: Based on your update, if you are merging disconnected tables you might want to consider using GUID keys so you don't have problems with collisions.
I suggest you to choose identity (Auto Increment) because when you use custom primary key you should generate an random number and then save it. when identity (Auto Increment) don't need. and when you use GUID sql or you have to generate a GUID and then store it. identity (Auto Increment) is more general and easy to understand too.
Related
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 5 years ago.
Improve this question
Dimension Lookup-Update create null data on dimension table. Anyone know how to avoid that?
Thanks.
Don't.
Keep it.
It avoids a lot of future referential integrity problems by providing with some kind of default in case the value of the natural key is not found.
It does not harm, because you can always query with technical key >0, if you need a list of existing cases.
Now you are warned, and if you fancy lots of NullPointerException and Foreign key integrity violation, nothing prevents you to remove the technical key =0 from the dimension table with a Delete step.
And an additional recommendation: do not alter the slowly dimension table to add manually an auto-increment on the technical key. Let the PDI do it's job as programmed.
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 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 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.
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 4 years ago.
Improve this question
Best practices for database logic in or out of database. Save logic in database?
What is the best practice as far as saving enumerations and other lookup data in or out of the actual database? For instance in a web store is it okay to save all of the products if you are still going to write code to put the data into and out of the tables that use this product information. What if you had user information like roles (manager, employee, etc). Would it make sense to have a lookup table for the roles or can your CRUD logic keep all of that and when a new user is added/updated the CRUD code can do that validation?
This may or may not be a community wiki that is fine if it needs to be tagged as such. I really just want more information and to know what others are doing.
EDIT: Great answers. And the consensus seems to be yes, put the constraints in the database. So my next question is what is the technical mechanism to make that happen. If I have a "roles lookup" table, and I go to add a new user. How do I say, the roles column for a new user must be one of any of the values in that lookup. I know how to do this in code but what is the SQL mechanism to do this?
The database is for data, and validation rules that enforce the integrity of that data.
To answer your specific question, yes, I would store users/roles in the database. There is no case in which I would want to have to update code in order to add users to the system.
The database is the place to enforce any logic that must be enforced to ensure data integrity. Doing that only in the application is a recipe for disaster, databases are not changed only by the application.
In part you need the lookup tables to ensure data integrity, so that values which are not part of the lookups cannot be added.
To answer your second question, look-up foreign key constraints.