Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was wondering if there is some sort of standard regarding the naming of MySQL Tables? I currently have two tables, one called Users and one called Trainings. Because i need them to have a many to many relationship it is required to create a table that interconnects these two but I am unable to think of a proper naming other than Users/Trainings.
No official best practice, but some well tested heuristics...
If my ORM or something doesn't enforce it's own standard, I like to use the underscore separated notation, but always in alphabetical order. Also, I always use singular for my classes and table names to avoid the puralization futz. Many to many by it's nature you can't tell what 'has' the other thing, so the alphabetical rule just makes it easier.
user
address
zebra
address_user
user_zebra
One simple set of rules, no confusion or ever as to how/what to name things, and easy to explain.
Going a step further, I recommend unless a very specific reason compels against it:
Always use lower case for tablenames and column names (that way you won't be suprised moving from a case sensitive file system to a case insensitive one--it's also easier not having to remember camel case)
name primary keys for a table (when not composite keys) id
name foreign keys in the format tablename_id (like user_id, zebra_id)
Remember, just Guidelines, not dogma.
These guidelines will make your life and your future dba's life better.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am working on a project where I am using a table with a multi-valued attribute having 5-10 values. Is it good to keep multivalued attributes or should I normalize it into normal forms ?
But I think that it unnecessarily increases the no of rows.If we have 10 multi values for an attribute then each row or tuple will be replaced with new 10 rows which might increase the query running time.
Can anyone give suggestions on this?
The first normal form requests that each attribute be atomic.
I would say that the answer to this question hinges on the “atomic”: it is too narrow to define it as “indivisible”, because then no string would be atomic, as it can be split into letters.
I prefer to define it as “a single unit as far as the database is concerned”. So if this array (or whatever it is) is stored and retrieved in its entirety by the application, and its elements are never accessed inside the database, it is atomic in this sense, and there is nothing wrong with the design.
If, however, you plan to use elements of that attribute in WHERE conditions, if you want to modify individual elements with UPDATE statements or (worst of all) if you want the elements to satisfy constraints or refer to other tables, your design is almost certainly wrong. Experience shows that normalization leads to simpler and faster queries in that case.
Don't try to get away with few large table rows. Databases are optimized for dealing with many small table rows.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In MySQL Workbench 8.0, I named the table such as Smartphone Brand.
But it automatically named in smartphonebrand after created which is very annoying and hard to find the name without the uppercase letter or whitespace character.
Anyone have any naming convention for schema and table in MySQL?
Use lowercase (a-z), digits (0-9) and the underscore character (_) for table names.
This convention provides optimal usability and portability. This is documented in the MySQL Reference Manual here:
https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html
Excerpt:
To avoid problems caused by such differences, it is best to adopt a consistent convention, such as always creating and referring to databases and tables using lowercase names. This convention is recommended for maximum portability and ease of use.
An entity identified as "Smartphone Brand" can be implemented as tablename smartphone_brand.
Another convention I tend to follow is to name tables in the singular; naming what one row in the table represents. Why I would not name the table smartphone_brands.
Also use full words and avoid abbreviations. Also avoid prefixing/suffixing table names with object type identifier such as tbl_smartphone_brand or smartphone_brand_table.
--
Of course its possible to produce a successful software project following other conventions. The conventions I follow are just one possible pattern.
As an industry professional, once we run into significant problems with the other database identifier conventions (as in what should be a simple port of a database application from Windows to Linux turns into a laborious grind), which could have been avoided by following a different convention, we discover that those features that we might currently identify as minor annoyances turn out to be tremendous time savers.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a table with 96 columns . the problem is i get confused for create this table with a large amount of columns.
Don't do that, then!
It's rare to genuinely need a table with that many columns. Most likely, you will be able to split the data across multiple tables into a relational database. For example, if, in your long table, each record contains the name of a product, the price of the product, the store that sells the product, and the address of the store, you will usually want to have separate Stores and Products tables, probably with a many-to-many relationship between them.
To a large extent you can do so without much thought, by putting your database into some normal form, typically the third normal form. These normal forms are chosen to have nice properties when you want to insert, update, or delete a record. However, you usually have to think about the meaning of the data you store to find a decomposition that makes sense. A lack of repetitions in the initial data doesn't mean there won't be any later.
Read more
Those concepts are well explained in the Manga Guide to Databases.
This answer gives an example of a situation that requires partitioning, and another answer by the same user explains the performance benefits. (Besides not confusing oneself.)
But I need to!
In some odd situations, you might genuinely need a long table. Maybe you're starting a club for people who have exactly 95 names and so you need to store an identifier key (since there is no natural primary key in this case) and each of the names in order. In that case, you will have some test data you can use to immediately verify that the table has the correct format.
To avoid getting confused, it might help to use pen and paper (or a blackboard): write out the test data in the order that's most natural, find a reasonable name and format for each column, and then work off that when writing your table creation procedure. The line numbers in your editor should be enough to make sure you haven't skipped a column.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
This question has been asked many times regarding entity tables.
What about a many-to-many (aka cross, join, pivot, etc, etc) table?
For instance, I have entity tables "courses" and "students", and a many-to-many table "students_taking_courses".
What are the pros and cons of deleting the joining record versus adding a flag column to the table and marking it as being deleted? What conditions would make one approach preferred over the other?
EDIT. Please assume the the two entity tables have surrogate primary keys.
Assuming usage of RDBMS, when having a flag instead of physical delete:
We will keep full trace of actions in the system. When having a
history is crucial this approach will be beneficial.
On the other hand
By keeping records, we will need more space
There will be more updates, in heavy load or high concurrency systems
that may be a problem.
More complexity will be imposed to the design, think about when we
need to force a unique constraint to course-student (many to many)
table, showing a course can be taken by a student once in a term.
Having the flag, we will need more effort than using DBMS unique
constraint.
I prefer an EAV approach for historical data over using the flag.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So far in my experience, every piece of data saved inside table's columns did not have a specific reason to be integer or boolean or so on. Yet again, we all are advised to use column type based on the data type. And I have been doing so for years now.
I am thinking to completely drop this idea and to use tables only with TEXT columns. It's easier to create them (don't have to write type but can copy/paste TEXT), compiler will warn me when type conversion is needed, and dozens of reasons like these ones.
Is there a good non-beatable reason why I should not switch to this practice?
No we don't complicate database tables with non-TEXT columns, instead we make the database provide a consistent format for the storge of the data.
By using number, boolean and date fields we get all the wonderful validation and retrieval methods that the database has implemented for these fields.
Without using the specific datatypes we will start reinventing the wheel when we need validations and specific display formats.
I once worked in a data warehouse group and it frequently made me want to have better defined datatypes, formats, required fields and validations on most of the data received.