Database design - alternatives for Entity Attribute Value (EAV) - sql

see How to design a product table for many kinds of product where each product has many parameters for similar topic.
My question: i want to design a database, that will be used for a production facility of different types of products where each product has its own (number of) parameters.
because i want the serial numbers to be in one tabel for overview purposes i have a problem with these different paraeters .
One solution could be EAV, but it has its downsides, certainly because we have +- 5 products with every product +- 20.000 serial numbers (records). it looks a bit overkill to me...
I just don't know how one could design a database so that you have an attribute in a mastertable that says: 'hey, you could find details of this record in THAT detail-table".
'in a way that you qould easely query the results)
currenty i am using Visual Basic & Acces 2007. but i'm going to Visual Basic & MySQL.
thanks for your help.
Bob

I would go with something like this:
product [productid, title, price, datecreated, datemodified, etc]
attribute [attributeid, title]
productattribute [productid, attributeid, value, unit]
Example:
[product]
productid title price datecreated datemodified
1 LCD TV 99.95 2010-01-01 2010-01-01
2 Car 12356 2010-01-01 2010-01-02
3 B/W TV 12.95 1960-01-01 1960-01-01
[attribute]
attributeid title
10 Colors
11 Dimensions
12 Passengers
[productattribute]
productid attributeid value unit
1 10 16 million
1 11 32 inch
2 12 4 adults
3 10 2 colors
3 11 6 inch

It seems you probably need to learn more about the available design patterns when dealing with this sort of problem as there isn't a one-size-fits-all solution.
I recommend picking up a copy of Patterns of Enterprise Application Delvelopment to help you on your way. Sorry that I'm not able to answer your question directly (hopefully someone else here on SO can) but I think the answer given in the question you linked to is about as good as it gets.

Related

Second highest column

I have seen a similar question asked How to get second highest value among multiple columns in SQL ... however the solution won't work for Microsoft Access (Row_Number/Over Partition isn't valid in Access).
My Access query includes dozens of fields. I would like to create a new field/column that would return the second highest value of 10 specific columns that are included in the query, I will call this field "Cover". Something like this:
Product Bid1 Bid2 Bid3 Bid4 Cover
Watch 104 120 115 108 115
Shoe 65 78 79 76 18
Hat 20 22 19 20 20
I can do a really long SWITCH formula such as the following equivalent Excel formula:
IF( AND(Bid1> Bid2, Bid1 > Bid3, Bid1 > Bid4), Bid1,
AND(Bid2> Bid1, Bid2 > Bid3, Bid2 > Bid4), Bid2,
.....
But there must be a more efficient solution. A MAXIF equivalent would work perfectly if MS-Access Query had such a function.
Any ideas? Thank you in advance.
This would be easier if the data were laid out in a more normalized way. The clue is the numbered field names.
Your data is currently organized as a Pivot (known in Access as crosstab), but can easily be Unpivoted.
This data is much easier to work with if laid in a more normalized fashion which is this case would be:
Product Bid Amount
--------- ----- --------
Watch 1 104
Watch 2 120
Watch 3 115
Watch 4 108
Shoe 1 65
Shoe 2 78
Shoe 3 79
Shoe 4 76
Hat 1 20
Hat 2 22
Hat 3 19
Hat 4 20
This way querying becomes simpler.
It looks like you want the maximum of the bids, grouped by Product, so:
select Product, max(amount) as maxAmount
from myTable
group by product
Really, we shouldn't be storing text fields at all, so Product should be an ID number, with associated Product Names stored once in a separate table, instead of several times in the this one, like:
ProdID ProdName
-------- ----------
1 Watch
2 Shoe
3 Hat
... but that's another lesson.
Generally speaking repeating of anything should be avoided... that's pretty much the purpose of a database... but the links below will explain than I. :)
Quackit : Microsoft Access Tutorial
YouTube : DB Planning
Microsoft : Database Design Basics
Microsoft : Database Normalization Basics
Wikipedia : Database Normalization

Parsing column data in SQL Syntax to an SQL Query

I am trying to solve a business flow issue at my work and I have an idea that I hope is technically feasible in SQL. What I would like to try and do is store different formulas in SQL syntax into database columns. Within SQL queries I would set variables to equal these columns so that the content of the columns is parsed as a part of the query and the different SQL statements pops up depending on the select specifications.
Short and sweet: I have some widgets to sell and whether or not a client can get these widgets depends on what other widgets they have bought, should have and shouldn’t have, country, customerid, their widget version, widget category and a couple of other things.
My question is how would someone proceed with this? I’m sure someone has made a similar setup before but which methods would be useful to study for my case? Are there case studies where I can find inspiration? I have searched for this without any luck. Hopefully someone who have solved similair issues before would be able to point me in a direction.
Thanks to whom‘ever is able to answer and has had the interest to read my post.
Best regards
Zaid
**OK this is more of a comment than an answer but the formatting doesn't work if I enter it as a comment!
To very vaguely answer your question I would have a Widgets table ie
WidgetID | Widget Name
1 Widget1
2 Widget2
3 Widget3
4 Widget4
Then have a WidgetRequirements table which is
WidgetRequiredID | WidgetID | RequiredWidgetID
1 1 2
2 1 3
3 1 4
4 2 4
5 3 1
6 3 4
This tells you that WidgetID 1 needs Widgets 2, 3 and 4 in order to be "active".
Widget 2 only needs widget4 to be active and Widget3 needs widgets 1 and 4.
This should get you started, expand on this theory.

in theory: would this be possible: SQL query for efficient use of build parts

I have a couple of tables, which I have simplified to the extreme for the purpose of this example.
Table 1, 'Units'
ID UnitName PartNumber
1 UnitX 1
2 UnitX 1
3 UnitX 2
4 UnitX 3
5 UnitX 3
6 UnitY 1
7 UnitY 2
8 UnitY 3
Table 2, 'Parts'
ID PartName Quantity
1 Screw 2
2 Wire 1
3 Ducttape 1
I would like to query on these tables which of these units would be Possible to build, AND if so, which one could be built first ideally to make efficient use of these parts.
Now the question is: can this be done using SQL, or is a background application required/more efficient?
So in this example, it is easy, because only one unit (unit Y) can be built.. But I guess you get the idea. (I'm not looking for a shake and bake answer, just your thoughts on this.)
Thanks
As you present it, it is efficient to use sql. As you described PartNumber column of table Units is a foreign key on ID column of Parts table, so a simple outer join or selecting units that the PartNumber are "NOT IN" the Parts table would give you the units that can not be build.
However if your db schema consists of many non normalised tables, or is very complex without indexes, other "bad" things etc
it could be examined whether specific application code is faster. But i really doubt it for the particular case, the query seems trivial.

MySQL: Getting connected (similar) data with lef/right fields

In MySQL Im having two tables:
PRODUCTS (id, Name)
SEEALSO (id, prodLeft, prodRight)
SEEALSO defines which PRODUCTS are related together and are represented as binded fileds "prodLeft"-"prodRight".
For Example:
PRODUCTS:
1 Desk
2 Table
3 Chair
4 Doors
5 Tree
6 Flower
SEEALSO
1 1 2
2 2 3
3 3 4
4 5 6
From that we can see binding of Desk-Table-Chair-Doors and Tree-Flower.
I would now want to write SQL statement where I could specifie PRODUCT name (e.g. Chair) and i would get result of binded fields that are connected with it (e.g. Chair: Desk-Table-Chair-Doors).
From this point on i would like to know if this is even possible for my data presentation concept in SEEALSO and if it is if you could help me solve my problem.
As you're wondering whether it's even possible, you could look into this information on Nested Sets, which is the MySQL way of doing this (I gather).
I could not give you a worked sample, as I'm no MySQL expert: perhaps this will help you enough given the general nature of your question.

Representing ecommerce products and variations cleanly in the database

I have an ecommerce store that I am building. I am using Rails/ActiveRecord, but that really isn't necessary to answer this question (however, if you are familiar with those things, please feel free to answer in terms of Rails/AR).
One of the store's requirements is that it needs to represent two types of products:
Simple products - these are products that just have one option, such as a band's CD. It has a basic price, and quantity.
Products with variation - these are products that have multiple options, such as a t-shirt that has 3 sizes and 3 colors. Each combination of size and color would have its own price and quantity.
I have done this kind of thing in the past, and done the following:
Have a products table, which has the main information for the product (title, etc).
Have a variants table, which holds the price and quantity information for each type of variant. Products have_many Variants.
For simple products, they would just have one associated Variant.
Are there better ways I could be doing this?
I worked on an e-commerce product a few years ago, and we did it the way you described. But we added one more layer to handle multiple attributes on the same product (size and color, like you said). We tracked each attribute separately, and we had a "SKUs" table that listed each attribute combination that was allowed for each product. Something like this:
attr_id attr_name
1 Size
2 Color
sku_id prod_id attr_id attr_val
1 1 1 Small
1 1 2 Blue
2 1 1 Small
2 1 2 Red
3 1 1 Large
3 1 2 Red
Later, we added inventory tracking and other features, and we tied them to the sku IDs so that we could track each one separately.
Your way seems pretty flexible. It would be similar to my first cut.