Need to identify the best way to contemplate this scenario :
The User can enter the system which fields he wants and what type of field
Example:
ID;Key;Type;
01;Name;Varchar;
02;Date;DateTime;
03;Gender;byte;
Then a 'tbRegister' table must store the information of the document registered by the user using the fields that it created.
Exemple:
Guid;DocumentID;Fild_Name;Fild_Date;Fild_Gender;CreateOn; CreateBy;
das215sa-15d1a-2d56as1;1;João;21/01/2001;1;30/11/2013 10:00:00; msantiago;
I also see a relationship between these tables. Something like:
FildByDocument:
idFild;DocumentID;
01;1;
02;1;
03;1;
01;2;
How would this in practice?
Like to meet a good structure. For such systems may contain very different types of documents
Got an exact example of what I wanted:
Thank you
I would do something like
Table_One_User
User_ID;INT; IDENTITY(1,1); --<-- Primary Key
01;Name;Varchar;
02;Date;DateTime;
03;Gender;byte;
Table_Two_File
DocumentID; --<-- Use INT not GUID (GUID is Not a good choice for Primary Key)
Fild_Name;
Fild_Date;
CreateOn;
CreateBy; Foreign Key --<-- Referencing to User_ID column in Table_One
-- You dont need to record Gender here you have
-- this information in Table one
Related
Let's say I have an entity CLIENT, which can be either PERSON or ORGANIZATION. Depending on which type it is, I have to choose attributes (address, name for organization, date_of_birth,first_name,last_name for person). I have created all three entities, but how can I make the attributes type-dependent?
Seen Database design: objects with different attributes, didn't help...
One typical choice is a 1:1 extension table:
create table client (id int primary key);
create table person (id int foreign key references client(id), ...columns...);
create table organization (id int foreign key references client(id), ...columns...);
However, my preferred choice is to include all columns in the client table. You can have a column for type that is either person or organization. Columns that are not relevant for the row's type can be null. Your queries will be much simpler that way.
Either you use 3 tables or you use 1 table and leave the not needed columns null. Which design is superior depends on the use case. Using only 1 table gives simpler queries but requires to change the table for each new subclass. Using multiple tables allows to add more types easily but gives more complicated queries. In doubt I would start with only 1 table but your mileage may vary.
Say I have field Ice_Cream.flavor, with the current choices in lookup table Flavor.flavor.
I use Flavor.flavor like an enum() list, storing the value, not the record ID, in Ice_Cream.flavor. If Flavor.flavor changes, I don't want to update Ice_Cream:flavor. I want it to stay as created.
Should I set up Ice_Cream.Flavor as a foreign key, so I can see the source of the values in my ER diagram, or not?
If you want Ice_Cream.flavor to stay as created even if there is no matching record in Flavor (which is what your question sounds like) then you cannot create a FOREIGN KEY relationship, it will not allow that condition to occur in your database.
Furthermore, if you're storing the actual text Flavor.Flavor string in Ice_Cream.Flavor, there's no particular reason to have a separate RecordID column in Flavor.
IMHO, you do not need a FK here except if you have additional informations about a flavor in the Flavor table beside the name in the column flavor. It is the case because you do not keep an ID, you keep the name AND you want to keep the old value.
I also supposed that you do not want to keep old flavors in the Flavor table or elsewhere except in the Ice_Cream table.
Last but not least, a FK would require that any flavor stored in Ice_Cream.flavor exists in the Flavor table. It is not the case if I understand correctly your question.
How do I store custom values in place of data types for the column.
I have a Table named as 'Orders' in which a column named as 'OrderStatus' and it's purpose will be to store the Status of the Order. For example R=Rejected, S=Sent, T=Returned.
I am very new to databases and design...
The 'correct' answer is to use Standard SQL-92's CREATE DOMAIN. Sadly, SQL Server doesn't support it yet. If you would like to see support you can vote for it here.
SQL Server has its own CREATE TYPE syntax but when I last looked I declared them not fit for purpose. If anyone disagrees, please post an answer to my question :)
This leaves two viable choices: a table with a foreign keys or CHECK constraints. The rule of thumb is that if the set of domain values is small and stable (e.g. the ISO 5218 sex codes) then use CHECK constraints, otherwise prefer a table with foreign keys.
In this case you don't really need a custom data type, you just need a foreign key to a table with all of your statuses in it.
Your OrderStatus table would look like:
id int PK NOT NULL, IDENTITY
code char(1) NOT NULL
description varchar(100) NOT NULL
(edit: note, as Martin pointed out in a comment on another answer, the surrogate id key isn't entirely necessary, but it allows flexibility for easily changing the code without having to update the data that refers to it)
Your Order table would then have a foreign key to this table:
order_status_id int FK NOT NULL
You can do that.
OrderStatus OrderStatusCode
----------- ---------------
Rejected R
Sent S
Returned T
Later, when you've got more 'design' under your belt, you go with a lookup table.
Best practice is to normalize, which means creating a table called ORDER_STATUS with the approved values in there, minimally with a schema like:
ORDER_STATUS(id number auto increment, code character, meaning varchar)
and then relate ORDERS to that table in a column called order_status_id, which would be a foreign key that would not be null.
I have an SQL table with basically the following structure:
PK (int, primary key), userID (int), data (varchar 64)
Basically, any user as defined by userID is allowed to store any number of short strings. However, no user is allowed to store two identical strings (although user 1 and user 2 can both store the same string separately). I would, if at all possible, like to implement this restriction at the database level because IMHO structural constraints should always be in the tables, as well as in the programs inserting/reading data from the tables.
The only thing I can think of is adding a third column in which I concatenate userID and data upon every insert, and call that column unique, but that seems too "hacky" to me. I am open to completely restructuring my tables if one of you guys has a better way of doing this that will allow me to put this constraint on the fields :)
Thanks!
Mala
Sounds like you need a composite unique constraint on the userID and data columns.
like this:
CONSTRAINT my_contraint_name UNIQUE ([userID], [data])
What if we have a unique constraint on UserId and Data. I hope it should solve your issue.
You want a composite key, which you can add to your table tablename like this in MySQL:
ALTER TABLE `tablename` ADD UNIQUE KEY (`userID`, `data`);
I think the simplest solution would be to create an index
create unique index ui on table (userID, data)
though there may be an overhead with this.
This kind of looks like it should be your primary key as well, though that really depends on the role PK and userId play in tables throughout the rest of the schema.
I think a composite key will do the task. Create a composite key with UserId and data columns. In this case, when a user tries to insert same data morethan once, it will throw error, which you can catch in your application and show the user an appropriate error message.
Hope it helps...
Thanks.
I have table named 'Dictionary' with columns as follow:
ID bigint
TYPE varchar (200)
ITEM varchar (200)
Table is used by various tables as simple dictionary / lookup.
Eg it stores countries, titles, business type lists.
TYPE column keeps info about type of dictionary , ITEM is dictionary string value.
All works well but I have problem to set up relationship between dictionary and foreigin tables.
When I'm using 'Foreign Key Relationship' I can not make it depended of 'TYPE" column.
(Please note same item with same type - eg 'countries' can be linked to several tables, when item with another type can be linked to different)
Currently I'm using USPs to manage that but I'd like to switch to standard relationship mechanism.
Any advice how to get that?
It looks to me that you could consider an alternative design
Dictionary table
ID (pk)
DICTIONARY_TYPE_ID (fk to dictionaryType)
ITEM
DictionaryType table
ID (pk)
DESCRIPTION
and then make links to the ID of DictionaryType table in places where you currently want to reference Type field from your original design
From the context of the question, I'm guessing you'll need to do one of two things:
Make your Type column the primary key
or have the foreign keys depend on the ID field here.
Foreign keys need to refer to a primary key, and it looks like your Type column isn't a PK.
what you have here is an EAV db design which is bad for number of reasons one being your problem. there is no solution for this in the real sense. you might try using sql_variant as a column type for the item and try to to a PK-FK relationship on that.
there's another way you could try to do this with the xml datatype and schemas like i describe here. however you'll have to test this to see if it applies to your problem.