Some people maybe know ER-Diagrams? The model of a database
e.g.:
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
So here is my database model:
(Translation: Werkstatt = Garage, Dienstleistung = Service, Kategorie = Category, Bewertung = Rating, bewerten = rate, besitzt = owns, hat = has)
My questions are:
1) I can model many-to-many relationships, one-to-one, one-to-many. Should I use own tables for them when needed? For example MANY-to-MANY relationship needs an own table.
Or will Laravel take care of the relationship by its Eloquent ORM?
2) You can design a database so good, that there can't be NULL-Values for example. Or that it handles dependencies or redundancy in a proper way (see http://en.wikipedia.org/wiki/Database_normalization#Normal_forms). Should I take care of redundancy and dependancy, or will again Laravel take care of that?
So in general I just want to know, how far should I go with my database design? Should I make it as good as possible, or is it enough just to create the basic entities?
Info: Here you can see the consquences which can happen if the database is not normalized:
http://en.wikipedia.org/wiki/Database_normalization#Free_the_database_of_modification_anomalies
Regards
It seems to me that there should be no direct relationship between USER and GARAGE. Rather, one USER should be be linked to RATING (one to many), and GARAGE to RATING (again, one to many). So I would have Ratings as a separate table, with each rating having a userid, a garageid, and a rating. I believe that in that case, you will not need a separate many-to-many table, unless you count the rating as the many-to-many table (which you shouldn't--Rating should have its own Eloquent model, in fact.) Disclaimer: I'm just a beginner at Laravel myself.
Related
I have the following issue with designing entity schemas.
Let's say that I've created a schema full of many-to-many relations, because it seemed like a reasonable choice at first, but during implementation those relations are not needed.
For example, theoretically each county can have many lakes and each lake can be located in many counties. But my database has no lakes crossing borders of the counties. Is it still reasonable to use many-to-many relations? It'll basically create a junction table that serves no need, because I can represent it with one-to-many relationships.
I have a geographical database that I intitially thought would contain a lot of many-to-many relations, but in practice such relations are needed only in a few tables.
First of all: It's related to your Software Functional Requirements.
Your System Analysts should decide on that. And System Analysts should follow System Owners, End Users, and other Stakeholders within the organization.
If you write a project for an organization or company, you should ask them.
Secondly: In Database Design, if you have even few countries that can have common lake, you should use many-to-many relationship. The reason is Extendability of your project. I don't think many-to-many has a lot of difficulties in comparison with one-to-many.
Thirdly: If you have a few (seldom) countries that can have common lake, I think you can use this data modeling technique:
You can use combination of one-to-many and many-to-many.
Add primary key of Country as F.K to Lake. (for one-to-many relationship)
Add new table like Country_Lakes with F.Ks from Country and Lake (to many-to-many relationship)
How to detect the Lake type (common or not): If the F.K of Country in Lake is NULL, this Lake is common, you can get all Countries from Country_Lakes.
In this design, you have a little Nullification, but it happens seldom.
If you might be using it, keep it. Creating many-to-many relationships afterwards is far more complicated.
If you won't ever use it, remove it.
I have to implement a testing platform. My database needs the following tables: Students, Teachers, Admins, Personnel and others. I would like to know if it's more efficient to have the FirstName and LastName in each of these tables, or to have another table, Persons, and each of the other table to be linked to this one with PersonID.
Personally, I like it this way, although trickier to implement, because I think it's cleaner, especially if you look at it from the object-oriented point of view. Would this add an unnecessary overhead to the database?
Don't know if it helps to mention I would like to use SQL Server and ADO.NET Entity Framework.
As you've explicitly mentioned OO and that you're using EntityFramework, perhaps its worth approaching the problem instead from how the framework is intended to work - rather than just building a database structure and then trying to model it?
Entity Framework Code First Inheritance : Table Per Hierarchy and Table Per Type is a nice introduction to the various strategies that you could pick from.
As for the note on adding unnecessary overhead to the database - I wouldn't worry about it just yet. EF is generally about getting a product built more rapidly and as it has to cope with a more general case, doesn't always produce the most efficient SQL. If the performance is a problem after your application is built, working and correct you can revisit and fix up the most inefficient stuff then.
If there is a person overlap between the mentioned tables, then yes, you should separate them out into a Persons table.
If you are only tracking what role each Person has (i.e. Student vs. Teacher etc) then you might consider just having the following three tables: Persons, Roles, and a bridge table PersonRoles.
On the other hand, if each role has it's own unique fields, then you should carry on as you are and leave each of these tables separate with a foreign key of PersonID.
If the attributes (i.e. First Name, Last Name, Gender etc) of these entities (i.e. Students, Teachers, Admins and Personnel) are exactly the same then you could just make a single table for all the entities with PersonType or Role attribute added to distinguish each person's role. However, if the entities has a lot of different attributes then it would be better that you create separate tables otherwise you will have normalization problem.
Yes that is a very bad way of structuring a DB. The DB structure should be designed based on the Normalizations.
Please check the normalization forms.
U should avoid the duplicate data as much as possible, else the queries will become slower.
And the main problem is when u r trying to get data that is associated with more than one or two tables.
I am trying to design a Person database. The requirement is that a Person can have one or more varying number of children, cars, jobs, and homes.
So, currently, the way I have designed this is:
Person {
CharField name
DateField dob
CharField city
...
# Some standard base person data
}
Since I want to support variable number of associations, I create separate tables with one-to-many relationships. For example, I have
Home {
ForeignKey Person
CharField home_address
...
}
Job {
ForeignKey Person
CharField company_nme
CharField office_address
...
}
And so on for other fields.
This works fine because I can have as many or as few entries per person.
The downside is that for each Person, I do lookup on 5-6 tables. I am going to need more fields, so the lookups will increase.
Is there a paradigm to efficiently design this kind of scenario?
If it is of interest, I use Django with PostGreSql.
Edit:
The server is mostly making REST API responses off the database. The browser client needs the entire data for one Person at one go (to reduce multiple requests over network). So I will have to do the multiple joins together.
Actually, for my Person table, I really do not need any relational-stuff. Other tables in my DB are heavily relational. The reason I am thinking of this now is because I suspect that the lot of joins will result in slower performance, and changing the design later will be difficult.
I also came across JSONField for PostGreSql and I was wondering whether I should use those to save the "hanging-off" data so that the REST calls do not result in a multitude of JOINS. Since this is design level, I am thinking of the issue now because I am not sure changing this going ahead will be feasible.
Thanks a lot for your inputs.
Your design is correct. The number of tables is a reflection of the complexity (or not) of the application.
The "paradigm to efficiently design this kind of scenario" is the relational model and you are designing in terms of tables because you are working within that paradigm.
Your notions about "the downside" and "lookups" and "efficiency" presume implementation aspects without justification. The DBMS takes your declarations and updates and answers your queries and hides how. Implementation issues do arise, but far from the level of experience and knowledge suggested by your question.
Just make a staightforward design.
Every time I program I recognize this relationship between classes and tables, or am I imagining it.
You can have a class per database table or a table per class i.e. :
tables: customer, products, order.
classes: customer, products, order, may have methods such as addRecord, deleteRecord, updateRecord.
what is this called? Object-Relational? I am not a DBA.
It all depends on the type of database you're using. If you're using an object oriented database (OODB), then there is no relationship, as the objects and the persisted data are the same thing. For example, if you have a Customer class, and you save it in an OODB, then that instance of the customer is what is stored in the DB.
If you are using a relational database, then the class instances, and the persisted representation of them in the DB, can be the same thing, but many times they aren't. This is because most folks use normalization to represent their data in an efficient way (in a relational DB). This means, instead of having a table per class, you can have a class represented by more than one table. In the Customer example, the tables might now be Customer (with Name, date of birth, and other properties), and Order (with order pointing to products in yet another table). The reason for this has to do with cardinality, and the ability for Customers to have more than one order. When your business logic needs this information from the DB, the data access layer's job is to map the data (called ORM) from the DB into your classes.
If you are using yet another type of DB, then there will be a different relationship between the classes (domain model) and what's persisted in the DB.
But, as far as having a name for this relationship? No, there is no name.
In additon to Bob's answer, the following.
In object modeling, the relationship between classes and subclasses is taken care of by inheritance, and object modelers know how to use inheritance to good advantage. The relational data model and by extension the SQL databases do not implement inheritance for you. You have to design tables to give you some of the same results.
In ER (Entity-Relationship) modeling, the corresponding concept is called generalization/specialization. This tells you how to model a class/subclass relationship, but it doesn't tell you how to design the tables when you go to build your database.
There are three techniques that are pretty well understood that can be really helpful when dealing with classes and subclasses. Here are their tags: single-table-inheritance class-table-inheritance shared-primary-key. Unfortunately, many tutorials on database design never cover these techniques. They can be enormously useful to people who know object modeling and want to come up to speed on relational modeling.
From my understanding, cakephp doesn't support database inheritance relationship. However, I want to create a database with different type of Users.
In this case, there are three types of Users: Seller, Customer, and Administrator. Every users should have basic User information such as password, username, etc.
However, each types of users will have its own unique set of datas. For example, seller may have inventory_id while customer may have something like delivery_address, etc.
I have been thinking of creating a workaround to this problem without destroying cakephp convention. I was going to create three additional foreign keys, admin_id, seller_id and customer_id, inside User table, which links to other table. However, knowing that this is an IS-A relationship not HAS-A, I would have to make sure that two of the ids are NULL value. Therefore, this workaround seems ugly to me..
Is there any other simpler, better approach?
For this type of database structure I would probably look at adopting an Entity-Attribute-Value model. This would mean your customer may have a delivery_address and your user may have an inventory_id but as far as your relationship in Cake is concerned your both your user and customer would just have an attribute_id ... you can then create another table that stores what type of attributes are available.
It it's simplest form, your user and customer would be attached to an *attribute_lookup* or *attribute_link* table by a hasMany (probably) relationship. That attribute_lookup/link table would be connected by a belongsTo/hasOne relationship to the actual Attribute Type and Attribute Value models.
Providing that you normalise your tables correctly, you can stick well within Cake relationship conventions.
You can read more about EAV here.
I have been thinking about this problem for some time now, and I have eventually got around to build a solution for it. What I came up with is a new ORM that can be used on top of CakePHP.
It sort of works as CakePHP 3.0 with entities that represent an id/model, but it is much more advanced and supports multi table inheritance and single table inheritance.
Check it out: https://github.com/erobwen/Cream