I'm looking to create a table for user preferences and can't figure the best way to do it. The way that the ASP.NET does it by default seems extremely awkward, and would like to avoid that. Currently, I'm using one row per user, where I have a different column for each user preference (not normalized, I know).
So, the other idea that I had come up with was to split the Preferences themselves up into their own table, and then have a row PER preference PER user in a user preferences table; however, this would mean each preference would need to be the exact same datatype, which also doesn't sound too appealing to me.
So, my question is: What is the best/most logical way to design a database to hold user preference values?
Some of the ideas that I try to avoid in database work, is data duplication and unnecessary complication. You also want to avoid "insert, update, and deletion anomalies". Having said that, storing user preferences in one table with each row = one user and the columns, the different preferences that are available, makes sense.
Now if you can see these preferences being used in any other form or fashion in your database, like multiple objects (not just users) using the same preferences, then you'll want to go down your second route and reference the preferences with FK/PK pairs.
As for what you've described I see no reason why the first route won't work.
I usually do this:
Users table (user_id, .... etc.)
.
Options table (option_id, data_type, ... etc.)
(list of things that can be set by user)
.
Preferences table (user_id, option_id, setting)
I use the new SQLVARIANT data type for the setting field so it can be different data types and record the data type of the option as part of the option definition in the Options table for casting it back to the right type when queried.
If you store all your user preferences in a single row of a User table you will have a maintenance nightmare!
Use one row per preference, per user and store the preference value as a varchar (length 255 say, or some value large enough to meet your requirements). You will have to convert values in/out of this column obviously.
The only situation where this won't work easily is if you want to store some large binary data as a User preference, but I have not found that to be a common requirement.
Real quick, one method:
User(UserID, UserName, ...)
PreferenceDataType(PreferenceDataTypeID, PreferenceDataTypeName)
PreferenceDataValue(PreferenceDataValueID, PreferenceDataTypeID, IntValue, VarcharValue, BitValue, ...)
Preference(PreferenceID, PreferenceDataTypeID, PreferenceName, ...)
UserHasPreference(UserID, PreferenceID, PreferenceDataValueID)
Related
I'm struggling to decide what database schema to use. One large table, or many small (though more difficult to manage).
I have 10 templates each with their own text fields. I am trying to store the text for the templates in a database and then when the web page is called I will show the correct text in the html template. Because a mixture of these templates are to be in a sequence of screens where you can navigate backwards or forwards, I need to be able to sequence them, I can only think of adding a page_number column. I also would like to re-order them and delete them as necessary using the page_number column.
I was planning to do all this in a web application without the need for a standard folder/web page structure, like a small CMS system.
option 1,
I can create one large table with many columns, lot's of which will be empty, over half with each row. Is this bad?
option 2,
I could create many tables using only the relevant template columns required.
The problem I see with this, is the headache of repopulating a column in each table when I delete a row, because I need to re-sequence a column that represents page numbers. Which I reduce if I use one large table.
I've thought of moving page numbers into another table called page_order but I cannot think of a way to maintain an effective relationship between the other tables if I make changes.
I'm yet to figure out how to re-sequence a column in a database when a row is deleted. Surely this is a common problem!?
Thanks for taking the time to help!
Have one table that contains one row per template. It might look like:
id (INT, auto-increment)
page_order (INT, unique key here, so pages cannot have the same number)
field1 (STRING, name of the text field)
value1 (STRING, contents of the text field)
field2
value2
Then you have to decide the maximum fields that any page can have (N) and keep adding field/value columns up to N.
The advantage of this is you have one table that isn't sparsely populated (as long as the templates have about the same number of fields, even if the names of those fields are different).
If you want to make an improvement to his (maybe not necessary for a small amount of data) you could change field to an INT id and connect it to a lookup table that contains (field_id, field_name).
I have a database in access for institute. there is a [Registers] Table and [Certificates] Table.
I want to give Mark to each of Registers a Mark. I want to set Validation Rule for Each
If [Certificates].[Mark]>70
Then UpdateRecord
SetField
CertificateID "GENERATE AutoNumber"
My Problem is i cant handle the CertificateID Generate with Macro. i cant use DMAX.
looking for a solution to give CertificateID to only Registers who passed the Course.
Tried "After Update" Macro and "After Insert" macro but still didnt success.
is there any other way to give AutoNumber except "DMax"?
Well, i just already found a way but not the best way.
I just added another Table as "Certificates" and renamed current(Certificates) to "Marks".
Tables and Fields
i made a query with Select a "Grade" from Certificates Table and rest from Marks. Whenever i fill a record in Grade table it generate Autonumber for "CertificateID" a new number.
For Validation i set my validation Rule in my form on Grade which i cant fill that field if Marks.Mark is less than 70. ( [Marks].[Mark] < 70)
I know its not a good way.
Still looking for better answer
Im using Asp.net (VB.net), in my Database :
have One table called (Trade), the same rows of this table are used from 3 different users, These users can make different updates on this table, they should see the basic informations of the table (I mean by the Basic, before the table (trade) has been updated)
The problem is here when the first user wants to modify the table's rows, the second and third user cannot see the basic information any more, and if they decide to change or update some data, the first will lose his updated rows..
The data will be overwritten every time the users make updates on the table.
What I want, is to know if there is a way to do like a copy, or an image of the table for the 3 users, and every user can update normally, without creating the same Table with the same rows 3 times??!
Update
My table structure is: Trade(trName, Carrier, POl, POD, Vgp, Qgp) There is no primary key..
Thank you..
Solution to your problem could be two copies of the original table. Show the original table always to the user as the initial data. And in second table keep the updated data always. Now the trick comes here to maintain the log, for that you have to maintain the log table, this table will have all the fields of original table along with one additional column "UserId", this will have the ID of user who has changed the value. Now each time before updating the data, copy it in the log table. If this suits your need then post the fields of your table then we can workout on the table structures.
I'm creating some url rewriting for asp.net. Now I am tobbing if I should include the id in url or just the title. Do you guys know if it's a significant performance hit to lookup an item by title instead of id?
If you can, lookup by the primary key, which is probably ID in your case.
However, if your titles are unique and you have an index on Title, the performance difference should be minimal.
Edit : Since is URLwriting, the title probably has better SEO mileage, FWIW
It depends on how many rows you have in your table and many other factors but generally if you have an index on your title column it shouldn't be too much of a performance hit. Ultimately the only real way to see if it's a problem in your scenario is to try it and run some tests.
The most important factor is to make sure you have have index on the column you are attempting to do the lookup on. So another way to say it is put an index on the columns in you where clause.
Enjoy!
That depends.
If the Id is the used for clustered id (default form PK) so the difference can be significant,
because in simple words, If you are using a clustered index to retrieve the data you do less operation.
The numeric type vs character. That also depend of the size that You have declared for this type. NUMERIC(20) is slower than VARCHAR(5).
In a specific table I have a SortOrder integer field that tells my page in which order to display the data. There are sets of data in the this field (based on a CategoryID field), and each set will have its own ordering. Users can add/remove/update records in this table.
My question is what is the best way to manage this SortOrder field? I would like to "reseed" it everytime a record is deleted or updated. Is this something I should be using a trigger for? Or should my code handle it and manage the reseeding?
What I used to do is use only odd numbers in the SortOrder field so upon changing the order, I would add or subtract 3 from the current value of the modified item and then do a reseed (order the items again using odd number indexes). Also I used to reseed after every insert or delete.
All you really have to worry about is swapping any two fields. All new entries go to the end and i'm sure you've got a mechanism by which the user can change the order. The order change, move up or down, really is a swap with a neighboring field. All you really care about is that all the fields are sorted properly. Don't let a mathematical sense of aesthetic drive you into creating something overly complex. (You'll end up with holes in your sequence after deletes are made but that's OK. It's an internal sequence marker used for ORDER BY. the numbers don't need to be made contiguous.)