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.
Related
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.
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'm working with a big mySQL database in IntelliJ.
I'm trying to join two tables which aren't in a direct key-relation to each other. Hence I have to join over multiple tables.
Because I barley know the database scheme, I can't find out these tables in a appropriate time. I know that IntelliJ has a function which can visualize all tables with their relations within the database but does it also provide a function where I can find out all tables in between two specific tables?
You can get help from Intellij partially for your task, using the visualization feature as follows-
The relationship between tables are clearly shown.
For your question, you need to check the primary and foreign keys for each table which are easy to know as they are highlighted.
Traversing them you can find the relationship.
I'm using mondrian-olap JRuby gem to query a datawarehouse using Mondrian library. I'm trying to build the OLAP schema but i'm having trouble setting a dimension composed by a many-to-many relationship.
I have a product with many categories, and so I created a table Product, a table ProductCategory and a table Category. The number of products is always increasing and so, using a single ProductCategory table seems a bit risky to me.
The Mondrian documentation was inconclusive for me, and all existing schema examples with a snowflake schema use only a single relationship table (like ProductCategory) and not a many-to-many combination of ones.
Is it possible to represent a many-to-many relationship using a Mondrian schema? Is there a better way to set this relationship?
Mondrian does not support many-to-many relationships. This is a feature that we have already started looking into, but there are no ETA as of now.
For example if I have 20 tables, I have to design it by section? i.e
CLIENT (id, name...) -- orders -- ODERS_DETAIL(id, products...)
.
.
.
lives --- ADDRESS(...)
Or I can use The MySQL Workbench EER Model (To me, it looks like the Pysical Model)?
Or like this: Data Modeling Levels
Well, I would not do it in code. That is for the RDBMS itself.
MySQL EER Workbench does not do true entity modeling - it is modeling tables, you are correct.
If you want true ER modeling I suggest Oracle's newly released ('Early Adopter') SQL Developer Data Modeler.
It is pretty easy to use, is free and can forward and reverse engineer models to tables. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html
When in doubt, design a table that is totally flat, and then determine where you have duplicated data, these can be considered for tables (entities).
The "ER model" defines entities unto themselves and allow the reference of entity-to-entity (table-to-table) through a separate relation. If you can remove yourself from thinking about foreign keys in your entities and focus on the relations in their own separate table.