I have a main Users table, but then i have a secondary Users_Info table, that contains personal info of every user, to follow the cakePHP naming conventions, how should I name this table if its supposed to be plural?
Thanks
Why not use something more intuitive like say a "profiles" table? Unless you are already using that for something else in your app. In your case remember that only the last word in your table name needs to be plural. Note that "users_infos" table sounds more like name for a HABTM table, only when following cake conventions you would order the table names alphabetically as "infos_users" for a HABTM table (http://book.cakephp.org/view/1044/hasAndBelongsToMany-HABTM). So to answer your question you should be able to simply add an s to your table name as stated above and it should work.
cheers
What serialk says is true: using a "profiles" table is the best schema design. Nevertheless, if you are unable to use "profiles" table, and since each user will generally have a single profile (Unless your application is providing option of multiple profile identities for each user), I guess you won't be needing a HABTM table "infos_users".
Coming to Cake's conventions, the conventions are designed to be as close to real world as possible. The table where books are stored is called Books and where categories are stored is called Categories. But the table where news is stored is still called as News and the table where information is stored is still called as Information, not Informations.
So, you can safely proceed using users_info table. It is not a violation of Cake's conventions. Cake will generate a UsersInfo model and a UsersInfo controller which you can use without any issue even though both or singular.
Related
I'm trying to design a system for giving users permissions on objects. Currently I have a database schema where there are roles and each role can have a permission on multiple 'securable objects'. Such an object can be a sensor, an other user or whatever new thing we might add later. So I have a table role_permissions that links a role to a user, sensor etc. A user can also have a permission directly, so there would also be a user_permissions table that link a user directly to a user, sensor etc.
Now the field that refers to a securable object can't be a foreign key, because the target objects can be of different types and thus come from different tables.
The problem I'm facing right now is how I can make Hibernate work with this. One-to-many relations won't work here I think because Hibernate can't possibly know in which table to look.
An alternative would be to create a role_user_permissions table, a role_sensor_permissions table, a user_user_permissions talbe, a user_sensor_permissions table, and a new role_other_type_permissions table + user_other_permissions table for every securable type that's in the system. So for every single type that needs to have permissions on it I would need 2 new tables to manage the permissions.
But now the database is cluttered with permissions tables that actually serve the exact same purpose but for different types. However, Hibernate IS happy to take this because through foreign keys it always knows what table to look in and what type the object is.
Does anyone know a best practice to solve this issue?
Thanks in advance,
Stan
I am working on a Project where I have below use case.
User can have many taglines for them , we have lot of predefined data in the DB which we using to show autosuggestion when they started typing tag lines, I am using Rails.
User has_and_belongs_to_many taglines
Tagline has_and_belongs_to_many users
I have separate joint table and everything was fine , but now I need to store custom taglines of user to DB , which will be belongs to only particular user.
Should I clone the taglines table and add user ID to it Or what is the best architecture to handle these kind of scenario , if we have more than one model which have same use case as like taglines.
your existing user and tagline table has many-to-many relationship, keep it that way. Whereas the user table and the new customTagline has a one-to-many relationship so why don't you create a new table to represent it? Since you mentioned the customTagline belongs to only a particular user.
#BroiSatse Comment make sense, I followed same.
If you create a second table, you will need to remember to update two
tables/models every time you will want to change your model. You won;t
be able to pull all the user tags in one go neither. many-to-many is
able to hold one-to-many association. Just add a validation to check
that given tag can belong to only one user if it is custom.
I am creating a DB for my project and I am facing a doubt regarding best practice.
My concrete case is:
I have a table that stores the floors of a building called "floor"
I have a second table that stores the buildings called "building"
I have a third table that stores the relationship between them, called building_x_floor
The problem is this 3rd table.
What should I do?
Have only two columns, one holding a FK to the PK of building and another holding an FK to the PK of floor;
Have the two columns above and a third column with a PK and control consistency with trigger, forbidding to insert a replicated touple of (idbuilding, idfloor)?
My first thought was to use the first option, but I googling around and talking I heard that it is not always the best option.
So I am asking for guidance.
I am Using MySQL 5.6.17
You don't need third table. Because there is one-to-many relationship between building and floor.
So one building has many floors and a floor belongs to one building. Don't get things complicated. Even though you need a table with composite keys, you should be careful. You need to override equals and hashCode methods.
I am still not confortable with that approach. I am not saying it is wrong or innapropriate, very far from that. I am trying to understand how the informations would be organized and how performatic it would be.
If I have a 1:* relationship, like a student may be attending to more than one subject along its university course within a semester I would Have the 3rd table with (semester, idstudent, iddiscipline).
If I try to get rid of the join table my relationship would be made with a FK inside student table or inside subject table. And it does not make sense to do that because student table is a table for a set of information related with registering the info of a person while the discipline table holds the data of a discipline, like content, hours...it is more a parametric table.
So I would need a table for the join.
Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html
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?