I am working on banking application, during the database design I have heard that primary key should be auto increment, but it is easy to use account number as primary key for the table account, which is the mixture and string and digit. So please mention is there any problem about using account_number as primary key.
A primary key is by no means required to use the auto_increment property - it just needs to be a unique, not-null, identifier, so the account number would do just fine.
There are, however, two additional considerations worth keeping in mind:
Numbers generally take up less space than strings, which usually makes their indexes smaller, and thus faster. If you have a complicated schema and use a lot of joins on the primary key in your queries, this difference may be noticeable.
Some DBAs advocate the practice of having primary (and other) keys that are separate from your data. That way, if you one day change your account identifiers (e.g., the bank acquires another bank and has to incorporate its clients into its system), you'll just have to update some data, and not all your keys.
There's no problem with it, and you don't need to auto_increment (but its handy). A Primary Key just needs to be a unique value that identifies its entry from other entries, and not null.
Primary key should be unique but not necessarily need to be auto_increment. As long is account_number is unique, there shouldn't be any problem.
Well, there is no need that the primary key is set to auto increment if we know the primary key is always unique. We set the primary key to auto increment because it is easy to handle. As you are making a bank software, the bank account number is always unique for every user. Therefore you can use that account number as a primary key. That's not a problem.
As long as the account number is unique, immutable and never NULL, it's not a problem to use it as a primary key.
If you aren't sure about the immutability it's probably not a good idea, things change and updating a primary key is generally not the best idea due to the fact that you also need to update all foreign key referencing it.
If you're not sure, a surrogate primary key along with a UNIQUE index on the account number is probably better.
Related
From what I have understand, we don't have Primary Key in the fact table and put a Surrogate Key is somehow a waste of space. Hence, the foreign key combination is the primary key for the fact table.
But I may case, I was not able to do that because the unique keys can potentially repeat in the fact table, e.g. same person paid twice on the same day, in same restaurant. In this cas, the primary key is no longer unique...
Is there anyway to solve this problème, without adding a surrogate key?
Thanks in advance !
If you are building a table like this a primary key or unique key combination is strongly recommended but if you are avoiding adding PK you may want to add unique transaction numbers so that you can do a combination of customer number and transaction number as the key combo.
InnoDB, if you don't provide a PK, will provide one for you. But it is 6 bytes and hidden. Compared to a 4-byte surrogate INT, this is bigger!
Check the data; there may be a "natural" PK that is a column or combination of columns.
Generally, for DW, the only index I have on the Fact table is the PK. Then I use "Summary tables" for the bulk of accesses. These are smaller and faster. In an extreme case, I will purge old Fact rows (via DROP PARTITION) but hang onto the Summary tables 'forever'. This keeps the disk space in check, while losing virtually nothing useful of the data.
Bottom line: Provide an explicit PK for every table.
I'm creating a database that has column of person's mobile phone number. Now i just want to know without making a separate column for id and making it a primary key, can i make this column a primary key for this table?
As noted above, you technically could use a phone number as a primary key, but it is not a best practice, because:
You would not be able to insert another user who happens to have the same phone number (primary keys must be unique).
You will run into what is known as an "update anomaly", if you have other tables that reference your tables primary key, and you decide to change a user's mobile number, you will have to also update the mobile number in all of the dependent tables.How to maintain referential integrity
From a performance standpoint, indexes on numeric values are usually more efficient than indexes on varchars, and will improve the performance on your joins, and the index will take up less space.
More often than not, your best bet is to use an auto-incrementing surrogate key.
Technically, you can define any column as primary key. The question is if such definition is good or bad. If you are going to use a phone number (that should be stored as string) and the column will not only be a primary key but also unique, and you will make sure that no attempt will be made to insert two times the same number for different people, then it should be OK.
I always see MySQL database primary keys as integers. Is that because primary keys must be integers, or because of ease of use when setting auto_increment on the column?
I am wondering just in case I want my primary key to be a varchar in the future.
You can use varchar as well as long as you make sure that each one is unique. This however isn't ideal (see article link below for more info).
What you are looking for is called natural key but a primary key with auto-increment and handled by the RDBMS is called surrogate key which is preferred way. Therefore you need to have it to be integer.
Learn more:
Surrogate Keys vs Natural Keys for Primary Key?
Why I prefer surrogate keys instead of natural keys in database design
Why Integers Make Good Primary Keys
It's often easier to use an integer for indexing, in comparison to a string or composite key, because it lends itself well to treating results (conceptually or in practice) as an array. Depending on the database implementation, integers may also be faster to access, sort, or compare, and the integer type usually offers additional features like auto-incrementing that aren't available for other data types. How would you go about auto-incrementing a composite key, for example?
MySQL has this to say about the primary key:
The primary key for a table represents the column or set of columns that you use in your most vital queries. It has an associated index, for fast query performance. Query performance benefits from the NOT NULL optimization, because it cannot include any NULL values.
SQL allows any non-null, unique column (or set of columns) to be used as a primary key. However, if you don't care about auto-incrementing, you can usually make your primary key any index that is UNIQUE and NOT NULL.
Consider Your Application's Expectations
While not a hard requirement, some frameworks optimize for integer primary keys. For example, Ruby on Rails facilitates the use of an auto-incrementing primary key by default; you have to deliberately work against the convention if you want to use something different.
That doesn't mean one should or shouldn't use integers as primary keys. It just means the choice of primary key is driven in part by your underlying database system and the queries you expect to run against it, and in part by the applications you expect to use to retrieve the data. All of those things should be taken into consideration when considering candidate keys.
A primary key is unique.int is easy to satisfy that condition with auto increment.If you make it char you have to create a way to make it unique whenever you add a data.
No, the primary key does not have to be an integer; it's just very common that it is. As an example, we have User ID's here that can have leading zeroes and so must be stored in a varchar field. That field is used as a primary key in our Employee table.
For a primary key to be an Integer, is easier to manage, and makes its index more effective.
As you know, while the keys are auto indexed, the indexes are stored as Binary tree which is best for integers in traversing.
There is no restriction on making a key to be int, you can declare it a varchar too.
Basicly a primary key needs to fulfill only 2 conditions: it has to be a not null column and it has to be unique. Any typeof column that respects this 2 conditions can be set as primary keys. In case the primary key is a multiple column one, then both columns need to be not null.
While in theory you can use other fields as primary keys, integers are the easiest to manage, as well as being the fastest indexes available.
I want to store in a table a list of IP ADDRESS to check later if some IP is already used in my system.
I want to store the ip in longip mode (signed int). And since each IP is unique i want to know if is necessary to have a primery key field (id, with autoincrement) or if its okey (and better) to just use my longip field as primary key.
if in the future you have to use the key for joining it with another table, the other table should contain all the number, and that's a lot of space wasted.
for example, you have a "computer" table
in that table, you have computes with ip's. For joining you need a key right? so, if you join by key, you should have the computer id and the key (in this case the ip)
I higly recommend to use a simpler id with autoincrement, like it's beeing done since mainframe (as400), iSeries, etc.
I think Marc_s' answer to the question When not to use surrogate primary keys? can guide us
I would say the following criteria must
be met:
your natural key must be absolutely, positively,
no-exceptions-allowed, unique
(things like names, social security
numbers etc. usually seem to be unique - but really aren't)
your natural key should be as small as an INT, e.g. not significantly more
than 4 bytes in size (don't use a
VARCHAR(50) for your PK, and
especially not for your clustering key
in SQL Server!)
your natural key ought to be stable, e.g. never change (OK, with ISO
country codes, this is almost a given - except when countries like Yugoslavia or the USSR collapse, or other like the two Germanies unite - but that's rare enough)
If those conditions are met, you can
consider a natural key as your PK -
but that should be the 2% exception in
all your tables - not the norm.
So I would say you should probably use a surrogate primary key. You can always use IP as a unique key if you want to
Since you're using the longip which as you pointed out is probably ok to use it.
Almost every time you start out with a natural key, you will end up regretting it later. Something will happen happen, its Murphy's law. Spare yourself the trouble, just add the ID column.
If its the auto-increment you don't like just use a uuid. MySql has a uuid function to make that easy.
Will it ever happen that we design a table that doesn't need a primary key?
No.
The primary key does a lot of stuff behind-the-scenes, even if your application never uses it.
For example: clustering improves efficiency (because heap tables are a mess).
Not to mention, if ANYONE ever has to do something on your table that requires pulling a specific row and you don't have a primary key, you are the bad guy.
Yes.
If you have a table that will always be fetched completely, and is being referred-to by zero other tables, such as some kind of standalone settings or configuration table, then there is no point having a primary key, and the argument could be made by some that adding a PK in this situation would be a deception of the normal use of such a table.
It is rare, and probably when it is most often done it is done wrongly, but they do exist, and such instances can be valid.
Depends.
What is primary key / unique key?
In relational database design, a unique key can uniquely identify each row in a table, and is closely related to the Superkey concept. A unique key comprises a single column or a set of columns. No two distinct rows in a table can have the same value (or combination of values) in those columns if NULL values are not used. Depending on its design, a table may have arbitrarily many unique keys but at most one primary key.
So, when you don't have to differentiate (uniquely identify) each row,
you don't have to use primary key
For example, a big table for logs,
without using primary key, you can have fairly smaller size of data and faster for insertion
Primary key not mandatory but it is not a good practice to create tables without primary key. DBMS creates auto-index on PK, but you can make a column unique and index it, e.g. user_name column in users table are usually made unique and indexed, so you may choose to skip PK here. But it is still a bad idea because PK can be used as foreign key for referential integrity.
In general, you should almost always have PK in a table unless you have very strong reason to justify not having a PK.
Link tables (in many to many relationship) may not have a primary key. But, I personally like to have PK in those tables as well.