I have a table for the "Features and benefits" of a list of products. In this table there is an item number, base part number, and three benefit columns. I want to change this to a dynamic table in which they can have any number of benefits, which I can do easily. The problem is the features and benefits do not change between items under the same base part number. For example under the base part "708" the items 708/s, 708/m and 708/l would all have the same features and benefits, so I want to get rid of the redundancy by removing the item column and just have a single entry for each distinct base part number. How would I go about this?
You might need to introduce a 'benefits grouper' field in your table, and relate that to another table with benefitsGrouperID, benefitSequence, and benefit
Related
I am developing an application for making quotations. First you make cost break down (or calculation) and upon that result you add item to quotation. The problem is that i have many product, so each category of a product will have its own cost break down form with different parameters to be filled in. If I will have only one table for cost breakdown, then it will be huge (a lot of fields in table). I have a feeling that this is not the right approach. So I came up with diagram below:
Is this solution even possible, or I must have "N" (if I have N-tables) different FK for each cost break down table? Do you have any better solutions?
I have another question if my linking table "Quotation_QtnDetail" is necessary?
It would be possible to store a reference to a particular value in one of these tables by having a CalculationType column indicating which table the record is in, along with a generic reference ID column (containing the ID of the relevant record). For example, if you were storing a CalcId of 123 and a CalculationType of 2, this would point to the record with ID 123 in the Calc2 table.
The downside to doing this is you're going to lose the ability to validate your data using FK constraints, and it will also make joins to your calculation tables a bit more complicated.
Regarding the Quotation_QtnDetail table, unless a QtnDetail record could ever be linked to multiple Quotation records, there is no need for this extra linking table. Instead, just link it directly by adding a QtnId column to the QtnDetail table. Similarly, you may also be able to remove the Calc_QtnItm table if an item is only ever linked to a single calculation record.
I have a model where a Shipment can have many Products through a product_shipments lookup table.
The Shipment model also has a relationship where a shipment can have one to many bill_of_lading numbers.
Is it proper to create a new table for just one bill_of_lading field ? Most cases a shipment will have only one bill_of_lading number, but often a shipment will contain 2 or more.
There are no other attributes for a bill_of_lading that need to be tracked other than just the number.
What is the proper way to handle this case?
Normalization rules would suggest pulling this out into its own table , correct ?
Yes, I would suggest you to do the same thing as you did with Shipment and Products, i.e. create new table. It is a proper way of doing it and easier for you to query later on and even altering your table structure should you need to.
Well, it wouldn't have one column, it would have two... a shipment ID and a bill_of_lading number. It could be correct to have a table with just those two fields. It could also be correct to create a field with bill_of_lading, shipment, and product if you can explicitly divide the products into individual bills of lading. It depends really on the relationship between bill_of_lading and product.
I name my tables according to what the row describes. So if it describes one comment in one row, I name it "comment".
I have a table with id, created_at, updated_at, name, description, quantity, sample. I am unsure what to name it due to "quantity". I think it can be seen in two ways.
The table describes one specific kind of item. There are x number of this one kind of item. As such the table should be named "item". Similar to fish vs fishes.
The table describes many items in each row due to quantity. As such it should be named "items". The caveat is that there can be 0 or 1 of the item.
I've also entertained the idea that quantity may be describing a subtly different entity and belongs in a separate table.
Ultimately, I think this is a style thing, but I think you should be consistent across your tables rather than trying to come up with a different concept table by table.
Personally I prefer singular because of the inconsistencies of pluralizing words, but a lot of people prefer plural because the table seems to be a collection of things.
In your example, though, I'm not sure why the presence of "quantity" as one of your columns would factor in. A table called "animal" could have a "number_of_legs" column, but I don't think that would change the way you think about the overall table of animals.
Item.
Each row contains a kind of item. A property of the item is the quantity. If each specific item had a separate row, and included a column such as SerialNumber, then Items would be appropriate.
Each row is not exactly describing an item, but an item bundle, right? Either way, don't overthink it.
From your question I would use 'item' because it's gonna be more similar to your other tables.
It might be a stupid question, but here goes:
Is it possible to make a dynamic table that's able to contain rows with variable number of columns and custom column names?
I have glanced over EAV-modelling, but it seems heavy. A real life example could be this:
Let's say I have a register with customers. But each customer might have different information to be entered. And depending on what you want to enter, it should be reflected in the database. (I.E. every customer has different columns)
Is this impossible/probable?
Update:
The standard approach (i.e. having a table with all needed columns and saving information only into columns that make sense for a particular customer while setting the remaining ones to NULL) doesn't work for me because what I want can't use 'fixed' column names. Example one customer might want CVR-number and another might want their phonenumber as a reference number. And a third might want some completely different information. So to avoid having a table containing 500 columns, I have now thought of making an extra table containing rows of column-data. Like so: Id, Name, Value, CustomerId. So when I want information for a customer, all I have to do is to iterate through this table with a specific customer Id.
my own edit!:
Sorry for troubling you with this simple SQL-issue! :-) Have a nice day...
You could model this as a one-to-many relationship between a Customer and a CustomerAttributes table. Something like:
**Customer table**
CustomerId
LastName
FirstName
...
**CustomerAttributes table**
CustomerId
AttributeName
AttributeValue
This is not possible in Sql-Server. As Marco says, you can store each customer's data in xml.
If all the columns are known ahead of time and some customers use one set and other customers use a different set, then sub-tables with each set of columns is the normal approach.
If the columns are not known ahead of time, then how would the data even be used? No code or reports could refer to it. Perhaps it should be stored unstructured in a general purpose 'Notes' field.
As far as I know it's not possible in standard relational databases, but you can take a look at schema-less databases called 'No-SQL' like MongoDB
I am designing a system for a client, where he is able to create data forms for various products he sales him self.
The number of fields he will be using will not be more than 600-700 (worst case scenario). As it looks like he will probably be in the range of 400 - 500 (max).
I had 2 methods in mind for creating the database (using meta data):
a) Create a table for each product, which will hold only fields necessary for this product, which will result to hundreds of tables but with only the neccessary fields for each product
or
b) use one single table with all availabe form fields (any range from current 300 to max 700), resulting in one table that will have MANY fields, of which only about 10% will be used for each product entry (a product should usualy not use more than 50-80 fields)
Which solution is best? keeping in mind that table maintenance (creation, updates and changes) to the table(s) will be done using meta data, so I will not need to do changes to the table(s) manually.
Thank you!
/**** UPDATE *****/
Just an update, even after this long time (and allot of additional experience gathered) I needed to mention that not normalizing your database is a terrible idea. What is more, a not normalized database almost always (just always from my experience) indicates a flawed application design as well.
i would have 3 tables:
product
id
name
whatever else you need
field
id
field name
anything else you might need
product_field
id
product_id
field_id
field value
Your key deciding factor is whether normalization is required. Even though you are only adding data using an application, you'll still need to cater for anomalies, e.g. what happens if someone's phone number changes, and they insert multiple rows over the lifetime of the application? Which row contains the correct phone number?
As an example, you may find that you'll have repeating groups in your data, like one person with several phone numbers; rather than have three columns called "Phone1", "Phone2", "Phone3", you'd break that data into its own table.
There are other issues in normalisation, such as transitive or non-key dependencies. These concepts will hopefully lead you to a database table design without modification anomalies, as you should hope for!
Pulegiums solution is a good way to go.
You do not want to go with the one-table-for-each-product solution, because the structure of your database should not have to change when you insert or delete a product. Only the rows of one or many tables should be inserted or deleted, not the tables themselves.
While it's possible that it may be necessary, having that many fields for something as simple as a product list sounds to me like you probably have a flawed design.
You need to analyze your potential table structures to ensure that each field contains no more than one piece of information (e.g., "2 hammers, 500 nails" in a single field is bad) and that each piece of information has no more than one field where it belongs (e.g., having phone1, phone2, phone3 fields is bad). Either of these situations indicates that you should move that information out into a separate, related table with a foreign key connecting it back to the original table. As pulegium has demonstrated, this technique can quickly break things down to three tables with only about a dozen fields total.