I am little confused if I should go in this way
I have tables like
| account | | Acc_registration_Info |
| AccID_PK | | AccRegInfo_PK |
| | | |
| | | |
Should I connect them between both primary keys? Also how to secure them in case of mismatching IDs?
I am trying to follow by Advanture Works DB structure, but this is little hard to understand, some of AW DB tables are splitted as hell (like users and their passwords in different tables).
I don't really feel confident about making so much tables and relate them one-to-one by PKs... My other hard decision is to connect Shop table with details shop informations table by PK, etc. etc.
On the other hand making too much non-primary columns to connect other tables doesn't look awesome
i think you have to make one primary key of a table the foreign key of the ather, that's how it work:
| account | | Acc_registration_Info |
| AccID_PK | | AccRegInfo_PK |
| #AccRegInfo_FK | | |
| | | |
like that if you want to know the reg info for an account you have just to pick the #AccRegInfo_FK of that account (in account table) and compart it to AccRegInfo_PK (in reg info table) and you ll get what you wnat , and of course what is called in relation databases joint
Related
I am new to django, and I have started the process of moving an existing API to Django. The current API has multiple databases.
For example, table account is in database A, table notification is in database B etc.
It is a legacy database on which the app is running, and as such, I cannot change the database.
For explanations sake, the structure of both are -
Account Table
+-----+--------------+
| id | account_name |
+-----+--------------+
| 123 | John |
+-----+--------------+
| 124 | Henry |
+-----+--------------+
| 126 | Vlad |
+-----+--------------+
Notification Table
+----+------------+-----------------------------------+
| id | account_id | notification_body |
+----+------------+-----------------------------------+
| 1 | 123 | Someone sent you a message |
+----+------------+-----------------------------------+
| 2 | 123 | Someone commented on your photo |
+----+------------+-----------------------------------+
| 3 | 126 | Someone sent you a friend request |
+----+------------+-----------------------------------+
In the above tables, notification.account_id is a foreign key with relation to account.id, which is the primary key in the account table. I want to join both the tables, the equivalent of the following SQL query.
SELECT * FROM A.account AS acc
JOIN B.notification ON noti ON noti.account_id = acc.id
Django uses foreign key to join tables using the select_related() function. Now, the problem is, I have foreign keys which are not limited to a single database. But, django as of now does not support foreign keys over multiple databases. So, how do we join those tables that are in another database in Django if foreign key related joins is not feasible?
Remember that both the tables are in separate databases.
I creating a database in which I have an artefact that can be associated with either a project, production or performance. I will call the relationship 'comes_from'. This relationship can be a project or a more specific version of a project such as a production or performance.
I don't want to have separate foreign keys on my artefact for each possible value of the 'comes_from' relationship as it feels wrong to have multiple attributes for the same relationship. The only way I can think of doing this is having a separate table that stores the comes_from relationship containing the id of the referenced project or more specific version along with the table the item is located in.
artefact table
+-------------+------------+
| artefact_id | comes_from | -- Foreign key to comes_from
+-------------+------------+
| 1 | 7 |
| 2 | 8 |
+-------------+------------+
comes_from table
+---------------+-----------------+---------------------------------+
| comes_from_id | comes_from (FK) | comes_from_table (FK table) |
+---------------+-----------------+---------------------------------+
| 7 | 19 | project |
| 8 | 13 | performance |
| 9 | 21 | production |
+---------------+-----------------+---------------------------------+
project table
+-------------+
| project_id |
+-------------+
| 19 |
| 20 |
+-------------+
performance table
+-----------------+
| performance_id |
+-----------------+
| 13 |
| 14 |
+-----------------+
production table
+---------------+
| production_id |
+---------------+
| 21 |
| 22 |
+---------------+
Is there a better way to do this as I am not sure I can even resolve this relationship in a SQL query and it may cause issues when I use Doctrine as an ORM on top of this database.
Your solution is good, the "comes_from_table" column could be a simple VARCHAR or INT indexed field acting as a discriminator field. However, I would remove the "comes_from" column from the "artefact" table and the "comes_from_id" column and use directly the "artefact_id" column to reference artefacts in the relationship table.
Regarding Doctrine there shouldn't be any problem, I did something similar in the past using Symfony2 and Doctrine2 for an entity called Tags where a Tag could either belong to a contact or to a contact spouse. I also created a function in the repository file where I could pass the "tag_type" as a parameter so that I could get either the contact or the contact spouse tags.
Hi I wonder which one of these database designs is better:
I have Shopping db, it has two tables: Categories and Brands. Both of those tables have the columns: name, description, and image_url.
So is it okay to keep the duplicate column? Or should I create a table that stores those information?
To visualize it better, here's a chart
The redundant one
| CATEGORIES | | BRANDS |
| - name | | - name |
| - description | | - description |
| - image_url | | - image_url |
or adding a new table?
| CATEGORIES | | INFORMATIONS | | BRANDS |
| |--->| - name |<-----| |
| - info_id | | - description | | - info_id |
| - image_url |
Thanks
In this case it's really NOT the same information. It's category_name, category_description, brand_name and brand_description.
Creating a table to keep generic information about many things is a bad idea.
When it comes to the discussion about (de)normalisation it's generally considered a better design to normalise data and I would start with such a design. As your data evolves and grows it might be necessary to de-normalise some tables as the data retrieval can be faster at the cost of storage space and risk of loosing data consistency.
Our Company is developing a CRM and we came now to the point where we have to decide how we want to handle the releationships. This is an important point because there are going to be tons of them. And changing the structure later would be simply not cool..
I know 3 ways how we could do it:
One releationship table:
The way i would do this is creating one table holding all the releationships.
Table: releationships
+----+-------------+-----------+--------------+------------+
| id | record_type | record_id | belongs_type | belongs_id |
+----+-------------+-----------+--------------+------------+
| 1 | person | 42 | company | 12 |
+----+-------------+-----------+--------------+------------+
| 2 | person | 43 | company | 12 |
+----+-------------+-----------+--------------+------------+
| 3 | note | 23 | company | 12 |
+----+-------------+-----------+--------------+------------+
| 4 | attachment | 13 | company | 12 |
+----+-------------+-----------+--------------+------------+
Multiple releationship tables:
I think this is the way how it for example the SugarCRM does.
Table: company_realationships
+----+-----------+------------+--------+
| id | record_id | has_type | has_id |
+----+-----------+------------+--------+
| 1 | 12 | person | 42 |
+----+-----------+------------+--------+
| 2 | 12 | person | 43 |
+----+-----------+------------+--------+
| 3 | 12 | note | 23 |
+----+-----------+------------+--------+
| 2 | 12 | attachment | 13 |
+----+-----------+------------+--------+
All in the record table:
Table: person
+----+-----------+------------+
| id | name | company_id |
+----+-----------+------------+
| 42 | luke | 12 |
+----+-----------+------------+
| 43 | other guy | 12 |
+----+-----------+------------+
ect.
So my Question is wich is the Best way of handling lots of releationships?
Are there other ways to do it?
What are disadvantages / advantages?
Is there a special way how hightraffic sides handle their releationships?
Thanks for your help guys :)
So my Question is wich is the Best way of handling lots of releationships?
The third one or the variation of it (see below).
Every "M:N" relationship should be represented by its own junction table. OTOH, a "1:N" relationship doesn't need additional table - just a proper foreign key in the table on the side of the "N".
If I understand your description correctly, the third option models a 1:N relationship between company and person. If by any chance you wanted to model a M:N relationship between them, you'd have a junction table: company_person ( company_id, person_id, PK (company_id, person_id) ).
Are there other ways to do it?
Sometimes, inheritance (aka. category, subtype, generalization hierarchy etc.) can be used to lower the number of possible "relatable" combinations. In a nutshell, make a relationship to a parent, then every child inherited from that parent is automatically involved in that relationship.
For an example, take a look at this post.
What are disadvantages / advantages?
Enforcing constraints (including FKs) declaratively is better (less prone to errors and probably more performant) than enforcing them through triggers, which is again better than enforcing them in the client code.
Choose a design that better adheres to that principle. For example, your options 1 and 2 don't allow the DBMS to enforce FKs declaratively.
Is there a special way how hightraffic sides handle their releationships?
Good logical design followed by good physical implementation is the only solid basis for good performance. It's hard to "bolt-on" the performance on top of a bad design.
Perhaps, you'd like to take a look at:
ERwin Methods Guide
Use The Index, Luke!
And when it comes to performance, don't guess! Measure on realistic amounts of data.
I am quite new to MySQL, I know most of the basic functions and how to send queries etc. However, I am trying to learn about structuring it for optimal searches for user information and wanted to get some ideas.
Right now I just have one table (for functionality purposes and testing) called user_info which holds the users information and another table that stores photos linked to the user. Ideally id like most of this information to be as quickly as accessible as possible
In creating a database which is primarily used to store and retrieve user information (name, age, phone, messages, etc.) would it be a good idea to create a NEW TABLE for each new user that stores all the information so the one table user_info does not become bogged down by multiple queries, locking, etc. So for example user john smith would have his very own table in the database holding all his information including photos, messages etc.
OR
is it better to have just a few tables such as user_info, user_photos, user_messages,etc. and accessing data in this manner.
I am not concerned about redundancy in the tables such as the users email address being repeated multiple times.
The latter is the best way. You declare one table for users, and several columns with the data you want.
Now if you want users to have photos, you'd require a new table with photos and a Foreign Key attribute that links to the user table's Primary Key.
You should definitely NOT create a new table for each user. Create one table for user_info, one for photos if each user can have many photos. A messages table would probably contain two user_id columns (user_to, user_from) and a message column. Try to normalize the data as much as possible.
Users
====
id
email
etc
Photos
====
id
user_id
meta_data
etc
Messages
====
id
user_id_to
user_id_from
message
timestamp
etc
I agree with both the answers supplied here, but one thing they haven't mentioned yet is lookup tables.
Going with the general examples here consider this: you have a users table, and a photos table. Now you want to introduce a featre on your site that allows users to "Favorite" photos from other users.
Rather than making a new table called "Favorites" and adding in all your data about the image (fiel location, metadata, score/whatever) all over again, have a table that effectively sits BETWEEN the other two.
+-----------------------+ +-------------------------------------+
| ++ users | | ++ photos |
| userID | email | name | | photoID | ownerID | fileLo | etc... |
+--------+-------+------| +---------+---------+--------+--------+
| 1 | .... | Tom | | 35 | 1 | ..... | .......|
| 2 | .... | Rob | | 36 | 2 | ..... | .......|
| 3 | .... | Dan | | 37 | 1 | ..... | .......|
+--------+-------+------+ | 43 | 3 | ..... | .......|
| 48 | 2 | ..... | .......|
| 49 | 3 | ..... | .......|
| 53 | 2 | ..... | .......|
+---------+---------+--------+--------+
+------------------+
| ++ Favs |
| userID | photoID |
+--------+---------+
| 1 | 37 |
| 1 | 48 |
| 2 | 37 |
+--------+---------+
With this approach, you link the data you have cleanly, efficiently and without too much data replication.