I'm trying to represent a simple classification scheme via a relational database. Or more specifically I'm trying to figure out if it's a good idea or not.
When I look at an image such as this http://www.talkstandards.com/wp-content/uploads/2009/10/taxonomy-of-standards.jpg, that I just picked off google, I see a bunch of one-to-many associations. that this happens to be amphibians is purely coincidental as I'm not a biologist.
I'm pretty new at databases and just wondering if there is a good way of dealing with a hierarchical taxonomy like schema
Just an example : same table case
Make a column to forein key parent and a column for the level
At top level node is 1 and parent is null;
Related
I am working on extending the existing project which has been in production for couple of years and I need to extend a few existing entities, lets call them a,b,c,d.
When I now think about the designing of a database all the a,b,c,d should have some sort of inheritance, but changing the schema too much is impossible at this point.
Now all the a,b,c,d have their own primary keys but they all have to implement certain interfaces like - "bookmarkable", "taggable", "viewable" etc.
Would it make sense to keep creating tables like
a_saved, b_saved, c_saved, d_saved or a_tags, b_tags, c_tags etc to model the relation? But then again.. I would have to create THE SAME code to handle each of the scenarios where the only difference it's the table name!
I think better solution would be to create an new table - lets call it "object" and try to model some inheritance - for each entity create an entry in the "object" table and store that id in it's table and then create one relational table to map object_tag relation.
Does this sound like feasible solution or possibly error-prone and will bite me in the feature?
A similar solution to your second idea would be to create a single table that maps an extension by a combined (entity type, entity ID) key. See here for a sample schema and query: http://sqlfiddle.com/#!9/3c0235/1/0
I'm designing a website with courses and jobs.
I have a jobs table and courses table, and each job or course is offered by a 'body', which is either an institution(offering courses) or a company(offering jobs). I am deciding between these two options:
option1: use a 'Bodies' table, with a body_type column for both insitutions and companies.
option2: use separate 'institution' and 'company' tables.
My main problem is that there is also a post table where all adverts for courses and jobs are displayed from. Therefore if I go with the first option, I would just need to put a body_id as a record for each post, whereas if I choose the second option, I would need to have an extra join somewhere when displaying posts.
Which option is best? or is there an alternative design?
Don't think so much in terms of SQL syntax and "extra joins", think more in terms of models, entities, attributes, and relations.
At the highest level, your model's central entity is a Post. What are the attributes of a post?
Who posted it
When it was posted
Its contents
Some additional metadata for search purposes
(Others?)
Each of these attributes is either unique to that post and therefore should be in the post table directly, or is not and should be in a table which is related; one obvious example is "who posted it" - this should simply be a PostedBy field with an ID which relates another table for poster/body entities. (NB: Your poster entity does not necessarily have to be your body entity ...)
Your poster/body entity has its own attributes that are either unique to each poster/body, or again, should be in some normalized entity of their own.
Are job posts and course posts substantially different? Perhaps you should consider CoursePosts and JobPosts subset tables with job- and course-specific data, and then join these to your Posts table.
The key thing is to get your model in such a state that all of the entity attributes and relationships make sense where they are. Correctly modeling your actual entities will prevent both performance and logic issues down the line.
For your specific question, if your bodies are generally identical in terms of attributes (name, contact info, etc) then you want to put them in the same table. If they are substantially different, then they should probably be in different tables. And if they are substantially different, and your jobs and courses are substantially different, then definitely consider creating two entirely different data models for JobPosts versus CoursePosts and then simply linking them in some superset table of Posts. But as you can tell, from an object-oriented perspective, if your Posts have nothing in common but perhaps a unique key identifier and some administrative metadata, you might even ask why you're mixing these two entities in your application.
When resolving hierarchies there are usually 3 options:
Kill children: Your option 1
Kill parent: Your option 2
Keep both
I get the issue you're talking about when you kill the parent. Basically, you don't know to what table you have to create a foreign key. So unless you also create a post hierarchy where you have a post related to institution and a separate post table relating to company (horrible solution!) that is a no go. You could also solve this outside the design itself adding metadata in each post stating which table they should join against (not a good option either as your schema will not be self documentation and the data will determine how to join tables... which is error prone).
So I would discard killing the parent. Killing the children works good if you don't have too many different fields between the different tables. Also you should bear in mind that that approach is not good to solve issues wether the children can be both: institution and companies but it doesn't seem to be the case. Killing the children is also the most efficient one.
The third option that you haven't evaluated is the keeping both approach. This way you keep a dummy table containing the shared values between the bodies and each of the bodies have a FK to this "abstract" table (if you know what I mean). This is usually the least efficient way but most likely the most flexible. This way you can easily handle bodies that are of both types, and also that are only of type "body" but not a company nor an institution themselves (if that is even possible or might be possible in the future). You should note that in order to join a post to an institution you should always reference the parent table and then join the parent with the children.
This question might also be useful for you:
What is the best database schema to support values that are only appropriate to specific rows?
I just started to take data base managements and I want to know something. Can I make a connection between 2 relations? I mean there wont be any entities or atributes between them. Is it correct If I do this?
In-order to make a connection between two relations (tables) each table must have one or more columns which can somehow relate to the other table.
From the following example we are able to make a relation based on the knowledge we know about animals, even though the two tables have no attributes or entities between them that are the same.
I'm defining a completely new database. I have now faced a problem
which I would describe as "usual" but still could not find good
information from web. So here's the problem:
I have many tables in my database (which I would describe as guides) such as:
Skills
Places
Activities
and so on...
Now to all these guide types I'd like to add a comment feature and
other similar features like attaching images and videos. I have many guide types so I dropped the idea of having a separate comment image and video tables for each of them. I need one table for each of them.
The question is, what is the best way to achieve this? I have heard and read about 3 solutions and I'm not familiar with none of them.
I have read about using UUIDs would fix this problem but I'm not very familiar how they function. Could someone elaborate on that if that is the correct way to go? Something about UUIDs I read but not quite understood it.
Other thing I have read about is creating a hierarchial model "tree table" which would hold association links. More info at Managing Hierarchical Data in MySQL.
I have also read about creating object tables and using program like object inheritance inside MySQL in a similar way like the hierarchical model.
UUIDs sound most simple so I would appreciate help in there.
I don't know anything about how to use them. But here's how I thought it works - at least you'll get a hang of it what I'm trying to achieve here and how/what I'm misunderstanding about them:
I would create a new table: Guides which could have UUID field.
Then link all those guide types (Skills etc.) to guide table (Guide as parent and the other as child)
Parent and Child have both UUID fields and when creating a guide Parent and Child gets same UUID so they can be linked. Child also has its own Id field.
Then link comments to Guides by using UUID field that points to Guide plus separate id int field for comments.
Please tell me if this is correct way or is it total garbage and if so, how I should do it?
Have you though about using a normal hasMany relationship with a condition? Read about it here.
class Skill extends AppModel {
var $hasMany = array(
'Comment' => array(
'className' => 'Comment',
'conditions' => array('Comment.type' => 1), // 1 for skills, 2 for places etc. or something like that.
)
);
}
Check http://cakeapp.com, create your DB layout there and download the SQL later.
I read more about UUIDs and since they allow application wide unique IDs I was able to do "inheritance" style of database.
I used my own prefix at the start of the every table name to avoid reserved table name collisions such as object. You can use any kind of prefix, for example: my_ and to use it like: my_object. All tables should use prefixes in this example.
So I created table Objects. It has the id field with Binary(36) type. Cake recognizes it as UUID field. Then I used 1:1 identifying relationships and inherited other tables from it, which I wanted to interact with others.
So I created 1:1 identifying relationship to Comments, Videos, Pictures table so that the table had the identifying foreign key being also a primary key.
Then I created Mappings table to which I used two 1:1 non-identifying relationships without primary key. This means this was really HABTM relationship to self.
Now this let me to "inherit" other tables from Objects table, like News table with again 1:1 identifying relationship. Then it was possible to link Comments, or anything other that has the 1:1 identifying relationship to Object, to News table by using the Mappings table.
I hope this will help others who are pondering this kind of solution aswell.
I am trying to build an Entity Framework model for my database schema using EF4 and Visual Studio 2010. Since I am stuck using MySQL as our database (for now), I pretty quickly discovered that since MYISAM tables don't support foreign key constraints, the designer does not have any way to automatically create all the associations for you. It is easy enough to go through the model and build them all manually, but I ran into a problem trying to map a pure join table.
Normally if you are using SQL Server or some other database that supports Foreign Keys, the designer will create all the mappings for you and in the case of pure join tables will create an AssociationSetMapping such that the join table is entirely hidden in the model. Instead you end up with a Many to Many mapping between two two primary entities.
However I am at a loss as to how to create this kind of mapping manually? If I create a Many to Many association between my two entities, I end up with a regular Association, not an AssociationSetMapping. There does not appear to be a way to create one of these in the designer than I can figure out, and to tell it which join table is supposed to be used at the database level.
Am I missing something, and there is a way to do this?
If not, I suppose I have to hack the XML directly, but at this point it is not clear what I need to add to the XML files and where, in order to manually create the association set mapping?
Ok, I can answer this one myself. Once you create a many to many association with the designer, you DON'T set a referential constraint on it, but rather use the Mapping Details window to tell the association what table is the join table, and which keys map to which fields in the database. Simple enough once I figured it out :) But I could not find any good documentation on this.