I am trying to figure out the MYSQL structure best practices for fields that contain more than one value. Should you ever have a field in a table that has comma separated values or should this logic always exist in a separate table?
For Instance I have an Organization and Post table. Within this table I have the following fields:
Organization:
ID - Integer
Organization Name - String
Admin - String
Sources - String
Post:
Post_ID - Integer
Title - String
Source - String (Value taken from list of "Sources")
Organization_ID - Integer (FK)
My "Sources" field contains a predefined list of domains that can be individually selected for each "Post". Currently I have a record for an Organization that contains Sources like "wikipedia.org","google.com"
I was wondering if this is the best way to store the values or if "Sources" should be its own table and link to the Organization.
It definitely sounds like you should make a many-to-many relation between organization and source.
I.e. you make a new table which has the ids from organization and source as foreign keys.
Related
I'm working on Access Microsoft 365. I have a table with 3000 entries, one of the fields is called "Artist" (includes the name of the artist). I've decided to turn this into a Lookup field, and make a table of the Artist names (so that they are all spelled correctly and the user can't misspell a name). Since the data is there already, how can I ask Access to use the data that's there and compare it to the Artist table (hoping that it's a match)? Everything I've tried deletes the Artist Name from all 3000 entries.
I advise not to build lookups in table. Just build combobox on form.
Do a Find Unmatched query to identify records in your data that do not have a match in Artists table. Access has a query wizard for that. Manually correct spelling for any bad records located.
You can save the artist name into your data but a better alternative may be to replace the name field in your data table with a number field for storing ArtistID. This will involve an UPDATE action SQL using a JOIN of the two tables on the name fields. Once the new foreign key field is populated, delete the unnecessary name field from your data table.
I'm trying to determine if this table structure is optimal for what i'm trying to achieve. Here is the current structure:
The option data table would have a many to 1 relationship with the option_field. Basically i'm trying to create a generic option system where you can create fields - the option data table relates the specific system entity (customer, user, package, service, customer package, customer service) using the corresponding fields. Customer Packages and Customer Services option data is defined when the customerid, customeraccountid and customeraccountpersonid have values as well as the packageid or serviceid.
the question i'm wondering is if it makes sense to have all those ID columns on the option_data record, or if it would make more sense to segment those out somehow. Ideally this option service would be generic enough that if i wanted to add more entity type options i would just have to add the corresponding ID field in the option_data table down the road. My only concern with this is that a good chunk of those id's will be null since not all option_data will ALWAYS use ALL the id fields in the option_data table.
hope this makes sense... not sure if this is the ideal table design for what i'm trying to acheive - please let me know if i can further clarify.
I have a users table in my database and have three kinds of user roles - manager(admin), expert, and student.
I have tried storing their role as column role in the users table, but my question is what is the best way to store it?
For example, should I use numbers - 1 for admin, 2 for expert and 3 for student. Or only one character - 'A' for admin , 'E' for expert and 'S' for student? Or full string 'admin' for admin and so on, or what?
Edit
Guys, I want most efficient way. Some of you told me to have another table but this relationship isn't many to many, it's one to many because users can only have one role.
You might want to have a separate junction table, eg user_roles that will have columns: id, user_id and role_id. This way each user can have multiple roles in the future, even if right now they only have 1.
And that role_id would point to a role in a new roles table, which could have all the data associated with the roles.
Or if you really don't want the junction table, then just put the role_id directly into your users table.
Look up database "normalization". Basically if you have a specific set of data that will be repeating in a column, you might want to put it in its own table.
You could create a separate table showing 2 columns: role_nbr, role with values like:
1, Admin;
2, Expert;
3, Student
Then include role_nbr in your users table and use numbers, linking it to the role table to lookup the role name. That way, if you ever increase your roles, it's easy to add to the separate table. A good study would be on normalization - this will help you eliminate storing duplicate information where you have a lot of information to store (like the role name - since storing a number or letter - how would you remember what it stood for?)
Use the enum type. Here is an example
CREATE TABLE users (
-- the other columns
role ENUM('admin, 'expert', 'student')
);
An ENUM is a string object with a value chosen from a list of permitted values that are enumerated explicitly in the column specification at table creation time.
This means that the enum type has already defined values (and can contain only one value per row - you can't have a user who is admin and at the same time student). In your case, they are admin, expert and student.
DOCS
I've seen various posts here about not using lookup within a table. If you don't, how do you enforce referential integrity between a field and the allowable values from a lookup table? I can't create a relationship between the table field and the field in the lookup table because I can't create a unique (no duplicates) index on the field - the particular value needs to appear multiple times across the records in the table. But if I use the field properties to set a lookup on it and specify the field from the lookup table that it must contain, then this ensures that data can't be entered into this field that isn't in the lookup table.
Or have I got completely the wrong end of the stick here?
I recommend that you always create forms for editing records. And in those forms you can create combo boxes that perform the lookups in the correct table and field. There are options there so that you can limit the data entry to only those values which are stored in the table. This option is called Limit To List (you'll see it in the combo properties).
Another important way to enforce that data exists in your lookup table is through your Relationships.
tblProducts
ProductID (primary key)
CategoryID (foreign key)
ProductDescription
tblCategories
CategoryID (primary key)
Category
In the relationships window you would define a relationship between the two tables above on the CategoryID field. You are accomplishing several things here. It's more efficient to store only the CategoryID in your Products Table since you will be storing less data. Also, this way if you change the name on the category all records will reflect that change immediately. Every place that you display a product with its category you will need to create a combo box so that you display the Category Description as opposed to displaying the CategoryID.
As a side note, I recommend that you rarely use the Value List option as the Row Source Type in a combo. Using the Table/Query option and then creating an appropriate lookup table is a much more robust and flexible design.
I have one MySQL table, users, with the following columns:
user_id (PK)
email
name
password
To manage a roles system, would there be a downside to either of the following options?
Option 1:
Create a second table called roles with three columns: role_id (Primary key), name, and description, then associate users.user_id with roles.role_id as foreign keys in a third table called users_roles?
Or...
Option 2:
Create a second table called roles with two columns: user_id (Foreign key from users.user_id) and role (ENUM)? The ENUM datatype column would allow for a short list of allowable roles to be inserted as values.
I've never used the ENUM datatype in MySQL before, so I'm just curious, as option 2 would mean one less table. I hope that makes sense, this is the first time I've attempted to describe MySQL tables in a forum.
In general, ENUM types are not meant to be used in these situations. This is especially the case if you intend to cater for the flexibility of adding or removing roles in the future. The only way to change the values of an ENUM is with an ALTER TABLE, while defining the roles in their own table will simply require a new row in the roles table.
In addition, using the roles table allows you to add additional columns to better define the role, like the description field you suggested in Option 1. This is not possible if you were to use an ENUM type as in Option 2.
Personally I would not opt for an ENUM in these scenarios. Maybe I can see them being used for columns with an absolutely finite set of values, such as {Spades, Hearts, Diamonds, Clubs} to define the suit of a card, but not in cases such as the one in question, for the disadvantages mentioned earlier.
Using ENUM for the case You suggested only makes sense when You have a strictly definded ORM on the receiving end that for istance maps db rows into a list of flat objects automatically.
Example:
table animal( ENUM('reptiles','mamals') Category, (varchar 50)Name );
is automatically maped to
object animal
animal->Category
animal->Name