I am creating an application that will require a user to register and create an account.
Should I use the person's Login ID (this is the email address) as the unique record identifier or should I also create a PersonID (or rec_id).
Why should I (or should not) create a rec_id ?
If you use the email address as a primary key in the Person table and foreign key in the related tables, it will be hard to implement the Change Email feature - instead of a single update, you will be forced to add a new record to the Person, update all the related records and then delete the record with old email.
Of course the person's mail address usually should be unique. But an additional record ID can be used as foreign key in other tables and so will make table joining much easier.
Related
I'm currently making a database for my java web app for Tourism.
Only register user can book a tour but can take along several people.
For this, I separate into User table and Guest table, each with its own primary key.
Everything is set so far, but when it comes to making my BookRoomDetail table, I have to fill in which person for which slot in the room. the problem arises when both register user and guest can fill this slot, and they're from 2 different tables.
How do I set the foreign key(or anything else) for this?
As I got your problem, you can add one more field for MainUser in your tblBookRoom Detail as a foreign key. And whenever any user books room you can add his/her primary key and guest primary key in forwhom field.
**tblBookRoomDetail**
ID (Primary key Of Table)
RoomId
For Whom (For MainUser or Guest)
MainUser (MainUser Primary Key Who is doing this reservation)
Slot
FromDate
ToDate
BookId
This is not possible to insert two different primary key value in a column of other table, if you have relation in them.
You can do this without the making the relation in them.
But it's not a good process because if the both key value same in this case you can't identify the actual.
If you want to achieve this goal then you should have a table tblAllUsers which primary key is also primary key of the tblGuest and tblUser and then you can make relation to tblBookRoomDetail table direct to tblAllUsers. In this case you can differentiate the Guest user or Registered Users.
or
Can Create the two different columns in tblBookRoomDetail, one for Guest user and second for Registered user.
Let's say I've 3 tables: enterprise, users, houses.
Everyone needs an address. What should I do?
Create a table address for everyone?
Create one unique table address?
Assuming that the first is "more" correct (cache, fragmentation, size, ...), how should I write it in plain SQL?
How do I create a "model" of the table address, and use it in custom tables (e.g. enterprise_address)?
* So when I change one field in the model, it gets replicated.
It appears you need every user to have an address. You have multiple ways to solve it.
Handle it in UI
Your users table will be just information about users (on address info here)
Create addresses table with addressid as primary key
Create many-to-many table/junction table called user_addresses that brings userid and addressid together
Ensure that your UI mandates address for each user
Tables
create table addresses (addressid int not null PK, line1, line2, city ...);
create table users (userid int not null PK, username, ...);
create table user_addresses (user_addressid int, userid int, addressid int, UK userid + addressid, FK to users, FK to addresses);
This allows a user to have multiple addresses. You have the flexibility of marking which one is primary.
Handle it in DB (and UI)
create table addresses (addressid int not null PK, ....);
create table users (userid int not null PK, username varchar(20), ..., addressid int not null, FK to addresses);
This allows one address per user.
and handle it also on the UI to ensure that address is supplied. Enter address into addresses first and then into users (make it an atomic process; use transactions!)
You can start with one these methods and analyze what your business needs are. Work with your DBA, if you have one, to see what their experience says about the business and previous DB designs similar to this.
Just from the three given tables I would assume that address is something you would want to put in either Houses or Users.
Depending on how much detail you want to keep track of in the Address it could be work making a separate table but there are a number of ways to go about this and the correct method depends solely on what you are trying to achieve.
Without knowing any of the required information all I can really advise is that you should aim to store the addresses as unique values. Once you have this you can assign each address to any other table you wish using a Foreign Key.
If you want to store multiple fields for the address then you will require a seperate table, if a single field will do then it could just as easily be added to the person or houses table.
One thing that would make a major difference to which way you would want to do this is the relationship between address and your other entities. For example if a user can have many addresses then you cant make it a part of the user table, and if an address can have multiple users assigned to it then it cant use a FK to represent its relationship to the users table.
One way you can do this is to make a relational table. So you make addresses and users seperate tables then have another table with just an id(pk) and 2 fks linking it to each of the other tables. This way you can have a many to many relationship if you wish.
First question: how many addresses per enterprise/user/house? If there are multiple addresses per entity, that leads you to want a separate address table, possibly with an address type.
Examples of multiple address situations:
Multiple locations
Ship-to addresses
Physical vs. PO Box
If you are going to assert that an entity can only have one address, then you probably prefer making the address part of the entity row, for simplicity. However, there can be reasons not to do that; for example, table width (number of columns in the table).
If you have multiple addresses per entity, typically you will use a foreign key. The entity should have an abstract key: some kind of ID. This will either be an integer or, in SQL Server, it could be a uniqueidentifier. The entity ID will be part of the key for the address.
Ok, I found the answer to postgresql: use INHERITS
e.g. CREATE TABLE name () INHERITS (table_model)
Thank you all for the answers.
I have a list of users in a table. When I delete a User and then create a user with the same account name, it takes the primary id of the deleted user.
The problem with this is, though a user is deleted, I keep track of what all users are deleted. When a new user takes the primary id of a deleted user, I have two instances with same primary id in my table.
I want the primary id to be different from the old one.
How do I do it?
This is a known behavior of AUTO_INCREMENT fields in MySQL:
http://forums.mysql.com/read.php?10,167180
If this is really your problem, you will have to find an other strategy to keep track of deleted user accounts.
For more information, see Stop MySQL Reusing AUTO_INCREMENT IDs
Im making an app where I have a server-side sql database to store the user settings of all users.
Im not sure how to make each user unique, so that the database knows who is who.
The database is storing these user data for each row: id, email, county, age and gender.
So im thinking the best way is to make the user unique to he/she's email - which is unique - so that the when the settings are updated or outputted, the sql knows what row to fetch.
How should I go about with this?
And how would i then output the right data to the right user?
An entity in the database should have a primary key. I understand that in your design the id field is going to be the primary key. Usually this is an auto-generated integer. This is called a surrogate key In this case you need to tell to the table that the email field must be unique as well. You can do that by creating a unique index for this field. The unique index will prevent the creation of two different users with the same email. Going with this approach you can query the table checking either for id or for email.
An alternative is to have natural key. In this case, email would be the primary key of your table, so you wouldn't have the id field. Going with this approach you can query the table checking either for email, which is the unique identifier of each user.
I have a case where the DB is set up with (simplifying) a table User and a table SuperUser. Both have a column Id. Every SuperUser row has a row in the User table with the same Id value (not my design!!!). The SUperUser table does not pull common info from the User table, it duplicates it.
Can/should any foreign key that points to User.Id also have a FK:PK relationship with SuperUser.Id? My take on this is it is at a minimum a very bad idea and that many (most?) DBs can't enforce this relationship/
Am I off base here?
Based on my understanding of your question you would run into two major problems with a foreign key set up to both the User and SuperUser tables.
You would not be able to enter or update any table with a foreign key set up like that unless the user was in both tables since the foreign key expects that userid to be present in both of them.
If you have the foreign key set up with a cascade delete and remove a record from the SuperUser then all tables with that set up would remove records associated with that userid potentially leaving you with just the record in the User table and all other information lost.
What would be a better option would be setting the userid column in the SuperUser table to be a foreign key of the userid column in the User table that way you will not run into issues where a user is not in both tables or removing a user from the SuperUser table.
Since every user has a record in the user table and I am assuming that not every user is a super user, I would just reference them by user and check if they are a super user when needed.
It would good to remove the duplicated fields if at all possible. This can easily become a nightmare to maintain as things grow.