I would like know the best way of designing a table structure for dependent column values.
If i have a scenario like this this
if the status of the field is alive nothing to do
if the status is died some other column values are stored somehow.
What is the best way to handle this situation
whether to create table containing all columns ie 'Died in the hospital','Cause of death','Date of Death' and 'Please narrate the event' and let it be null when status is alive
or
to use seperate table for storing all the other attributes using Entity-attribute-value (EVA) concepts
in the above scenario signs and symptoms may be single, multiple or others with specification. how to store this .
what is the best way for performance and querying
either to provide 15 columns in single table and store null if no value or to store foreign key of symptoms in another table (in this strategy how to store other symptom description column).
In general, if you know what the columns are, you should include those in the table. So, a table with columns such as: died_in_hospital, cause_of_death, and so on seems like a reasonable solution.
Entity-attribute-value models are useful under two circumstances:
The attributes are not known and new ones are added over time.
The number of attributes is so large and sparsely populated that most columns would be NULL.
In your case, you know the attributes, so you should put them into a table as columns.
Entity-attribute-value models is the best method, it will be helpful in data filtering/searching. Keeping the columns in the base table itself is against Normalization rules.
I am currently making a very simply database but haven't made one in a while.
My issue is that I have one table, Drinks, which has a column (the technical terms slips my mind) that is called ingredients. This column will be populated from two other tables, volume and ingred. I have split these tables up because there are many drinks that use the same ingredients but different volumes of them. So my question is what kind of query/relationship should I have to get the column to be correctly populated.
In your main table (Drinks) you need reference to splitted table. For example instead of ingredients field you need ingredients_id and the same for other splitted tables.
Then you can use one to many query to populate your data as you wish.
I have a cross reference table that contains three major columns:
object id
different object id
relation type between the two
Problem is, on some cases I need two more columns that help define the relation between the two objects.
My question is, what is the proper way to deal with the situation?
Should I create another table with five columns, and have two table for practically the same purpose?
Or is it ok to add two more columns that will almost always contain null. Will it needlessly affect response time and size?
Thanks
edit-
I've been asked for more information, so here it is:
the database hold philosophical arguments.
This specific table holds the information of which which statements are connected in what logic.
these are the columns:
statement_id
logic_id
direction
which are good for two-way logic (such as 'if-then');
But in case of a multiple statement logic (such as 'and' or 'or') I needs two more columns:
exit
inner-logic type
I'm not sure if this extra information helpful or just more confusing. feel free to ignore it and answer the question on purely academic base.
It is ok to have two ids and any number of columns describing the relationship. Those extra columns could be NULLable if they are optional or whatever.
It sounds like the two ids JOIN to a single table, correct? In that case, you may need to UNION two selects to check for an id in either of the columns. And have multiple indexes, one starting with one id, one starting with the other.
It would help if you provided SHOW CREATE TABLE and a SELECT or two. That might give us a better feel for what the tables are for.
So all of my other queries are working just fine. Except for this one that does not pull back any results.
$var = $pdo->prepare("SELECT id, sku, quantity, style FROM catalina_warehouse, branford_warehouse WHERE sku='$data_search'");
$var->execute();
I don't see the problem here but if I remove the comma in between the two table names then it works and only pulls from the first table but if I leave the comma there then no results are pulled.
You need to indicate on the columns on the select line which table those columns are coming from.
On another note, i am assuming that the 2 warehouse tables have the same columns, but they just represent 2 different locations. This is generally not a good DB design practice. you could run into normalization problems which could cause data integrity problems and redundancy. you should have a products table with all their assorted info as well as a column that indicates which warehouse it is housed in and another table that lists the warehouses and all their info. make the warehouse column a foreign key references the warehouse table and you're golden. This can help with data integrity and with query design. But if my assumption is wrong, ignore this.
Say I have a store that sells products that fall under various categories... and each category has associated properties... like a drill bit might have coating, diameter, helix angle, or whatever. The issue is that I'd like the user to be able to edit these properties. If I wasn't interested in having the user change the properties, and I was building the store for a certain set of categories, I'd have one table for drill bits, etc. Alternatively, I could just modify the schema online but that doesn't seem to be done very often (unless we're talking phpmyadmin or something), and plus that doesn't fit in well at all with the way models are coupled to tables.
In general, I'm interested in implementing a multi-table database structure with various datatypes (because diameter might be a decimal, coating would be a string/index into a table, etc), within mysql. Any idea how this might be done?
If I understand correctly what you're asking, an, admittedly hacky, solution would be to have a products table that has to related tables, product_properties and product_properties_lookup (or some better name) where product_properties_lookup has an entry for every possible property a product can have and where product_properties contains the value of a property as a string with the ID of the property and the ID of the product. You could then coerce the property value into whatever type you wanted. Not ideal, but I'm not sure what else to do short of adding individual columns to the DB for property types.
Just use the database. It does all of this already. For free. And fast. How is having a table of products point to a table of properties with data types any different from a table with columns? It's not. Save if you use the DBs tables you get to use SQL to query it in all sorts of neat, and efficient ways compared to your own (crosstabs suck in SQL dbs).
Get a new product, make a new table. No big deal. Get a new property, alter the table. If you have 1M products in that table, yea, it may be a slow update (depends on the DB). Do you have 1M products? I don't think WalMart has 1M products.
Building Databases on top of Databases is a silly thing. Just use the one that's there. It is putty in your hands. Mold it to your whim.
Create a Property table first. This will contain all properties. It should have (at minimum) a Name column and a Type column ('string', 'boolean', 'decimal', etc.). Note: Primary keys are implied for all these tables.
Next, create a CategoryProperty table. Here you will be able to assign properties to a category. It should have these columns: CategoryID, PropertyID. Both foreign keys.
Then, create a Category table. This describes the categories. It should have a Name column and possibly some other columns like Description.
Then, create a ProductCategory table. Here, you will assign the categories for each product. It should have these columns: CategoryID, ProductID. Both foreign keys.
Next, create a PropertyValue table. Here, you will "instantiate" the properties and give them values. Columns include ProductID, PropertyID, and PropertyValue. The primary key can consist of ProductID and PropertyID.
Finally, create a Product table that just describes each product with columns like Name, Price, etc.
Note how for each relationship there is a separate table. If you only want one category for each product, you can do away with the ProductCategory table and just put a CategoryID field in the Product table. Similarly, if you want each property to belong to only one category, you can put a PropertyID column in the Category table and get rid of the CategoryProperty table.
Lastly, you will not be able to verify the data type for each property since each property has a different type (and they are rows, not columns). So just make the PropertyValue column a string and then perform your validation either as a trigger, or in your application, by checking the Type column of the Property table for that property.
If you're using a recentish version of mysql (5.1.5 or greater) you can store your data as XML in the database. You can then query that data using thigns like this.
Suppose I have a table that contains some items and I have a widgetpack that contains numerous
widgets. I can get my total number of widgets:
SELECT SUM( EXTRACTVALUE( infoxml, '/info/widget_count/text()' ) ) as widget_count
WHERE product_type="widgetpack"
assuming the table has an infoxml column and each widgetpacks infxml column contain XML that looks like this
<info>
<widget_count>10</widget_count>
<!-- Any other unstructured info can go in here too -->
</info>
DB purists will cringe at this, and it is kinda hacky. But often its easier to keep all your unstructured data in one place.
Have a look at this database schema on DatabaseAnswers.org:
http://www.databaseanswers.org/data_models/products_and_generic_characteristics/index.htm
Maybe consider an Entity-Attribute-Value (EAV) approach (not for the whole model of course!).
Related questions
Entity Attribute Value Database vs. strict Relational Model Ecommerce question
Approach to generic database design
How do you build extensible data model