I need to create such a structure, there is a category of products, each category stores its own information, for example, be entered phone information when selecting a phone category, computer information must be entered when selecting a computer category, How to create this structure in a clean database? , how is it done in a real project?
Before creating a 'structure' in a DB you need to design your Entity-Relationship Diagram.
This means that you need to decide the Entities of your problem, these would be your tables later in the DB, the Relationships between the entities, these have multiple ways that can be depicted in the tables based mainly on their cardinality and then the properties of the entities, which will be the fields of the tables in your DB.
I think that you need to start from that, create the ER Diagram and then try to model it into the DB.
Related
New to this, I am creating a database for an application. As the schema is becoming visually complex very rapidly, is it possible/feasable/recommended to have the same user_table in multiple schema?
For example, the blogging schema would have the user_table and the rest of the tables related to this activity. The shopping schema would again have the same user_table and the tables to manage the shopping activity. And so forth....
The objective would be to separata the plenty of tables in different schemas so to simplify the overall managements.
In another post, someone suggested creating a synonym in one the of schemas, referencing the other schema table. Is it the way to go or am I totally misrepresenting problem and solution?
Thank you for your time reading this.
A user table serves two diffent features, each in its own schema:
Sharing tables between schemas is not directly possible. There's a feature called federated tables, which however is not enabled by default and must be enabled at compile time of a MySQL server. So, it's rather not available for your task.
Instead you have only two options:
Use a single schema to avoid data duplication.
Use multiple schemas and maintain tables like the user table in each of them in parallel (by executing the same update queries on each of them).
I have a hobby project where I am creating my own software that will have different modules. The idea is to make the modules stackable and can be toggled off and on. I am using MySQL as the database back-end, and am wondering if it is better to have module-specific tables on their own schema, or if te tables should be prefixed. For example, let's say I have a systems module and an employees module; would putting all tables related to employees on an employee scheme be better than just prefixing the table names with something like "emp_"?
Prefixing table names is usually unnecessary clutter; the table names or the tables you are JOINing to should make it obvious what is going on. There is no performance difference between all-tables-in-one-db vs several dbs; there is a slight syntax diff.
This is kind of a moot point for MySQL, because databases and schema are interchangeable in MySQL. It would be more relevant for SQL Server.
My MySQL the keyword database was renamed into schema because they are not separated database. You can still have relationships across schemas.
In some ORM such as Laravel Eloquent you can write relationships such as:
$company->hasMany(Employee)
In this kind of relationship you will have a pivot table named company_employee. If you have two separated schemas, where do you want to put your pivot table? On the company schema or on the employee schema?
Laravel will fail to solve this question and it not trivial to create such relationship across schemas.
I'm no MySQL expert and I have to design a rather complex db for my level.
The problem I'm facing now consist in having a supplier-customer relationship within the same table (macro categories of companies):
Macro table
id name mega_id macro_customer_id
------------------------------------------
1 Furniture 2 2,4,5,35
I want to represent the fact that macro entry with id 1 has other macro companies (which are their customers) described within the same table.
Which is the best way to represent this?
Thanks!
It depends: We all used to use the normalization forms (as #1000111 indicated), however depending on the use of the data, you can choose to look different at certain parts of this normalization discussion:
The normal model for this would be:
Table userData(id,name)
- 1:N table linkTable(id,macro_customer_id)
- N:1 table metaData(macro_customer_id,value)
Or:
Table userData(id,name)
- 1:N table linkTable(macro_customer_id,id)
The big question is however in how the data is used. If data is just for this user and not queried in any other way (no where, or group by), then storing it as a serialized String is a completely valid approach.
The relationship between entities in an RDBMS should be stored in a relational way. Ask yourself if you care about this relationship in your database - will you need to write queries that will link macro.id to table/rows represented by IDs in macro.macro_customer_id? If yes, then you must store this relationship in a (one-to-many or many-to-many) separate table.
I want to create a multi tenant app, but I have never worked with multi tenancy apps.
I would create a database global database for users and some data like zipcodes, countries, ...
And each tenant has his own database so they can store their data on their own server.
Now I have 2 problems:
If I connect to the user database I need to access to the shared
(global data), e.g. zipcode - is this possible?
I would create
dynamic forms, so the users have a table for the forms and the
fields and a datatable. The advantage of this method is that each
user can modify his forms, but is this a good practise?
Normally you have fixed table schemas like: customers (id, name, ...), addresses, so on.
Is there any better idea?
Hope someone know's what I mean and can help me :)
Thanks
Regards
Alex
mysql "databases" aren't real databases - they're just schemas inside one database.
You can query between schemas, and have foreign keys between schemas too. Just use the fully-qualified name: schema_name.table_name.
Dynamic tables (EAV) are almost always a bad idea. Use existing data model patterns first. If you really, really must use user-defined fields, then follow Martin Fowler's advice.
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