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.
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 4 years ago.
Improve this question
How can we evaluate whether a table's good or bad in a database system? What aspects do we need to analyse? Can I build a model for doing such evaluation? If yes then how?
A non-exhaustive list. For all these questions, yes is a good answer and no is bad.
Does the table serve a clear business function? How well does it fit the application's purpose?
Is the table well-named? Are the table's columns well-named? Would a business user understand what they mean?
Does the table have a primary key?
Does the table have unique constraints on all the business (candidate) keys?
Are all the foreign keys defined?
Do all the columns with constrained values have a foreign key to a reference data table or a check constraint (or an enum for MySQL)?
Do all the columns have the correct (strongest) data type?
Is the table correctly normalised? (In an OLTP environment that means at least Boyce-Codd Normal Form, things are different in data warehouses.)
Is the table free of any columns which hold "smart keys", CSV strings, JSON, XML, different data items whose meaning is dependent on metadata held in another column (or another table), or any other exotic structure which seemed like a good idea at the time but which will incur a legacy of horrible code and data corruption for years after?
Are all the columns scalar, using recognised Oracle built-in data types (i.e. no nested tables or user-defined types)?
Does the Physical Data Model diagram include the table?
Is the table derivable from entities in the Logical Data Model diagram?
Do you have scripts of the DDL for the table and its dependent objects? Are those scripts in source control?
Does the table conform to whatever modelling and coding standards you have (if any)?
Is the table physically implemented properly (e.g. all necessary indexes, index-organized if appropriate, partitioning if appropriate)?
Is the table defensible? How comfortable would you be explaining it to another experienced data modeller, database developer or business user?
As you can tell, this is an opinionated list (which is why some people have voted to close your question). Some points are rather imprecise. It's probably a long way from the model you were hoping for.
People will want to argue with some of these measures. For instance, the point about non-atomic data structures like JSON. Of course there are times when such structures are appropriate; I once worked on a system which would have been much simpler if we had stored the data in XMLtype columns instead of shredding it into relational tables. But those are isolated cases. Read some of the questions on this site about smart keys, tokenising CSV strings or writing queries against an Entity-Attribute-Value anti-model to understand how much grief these things cause. First Normal Form should be a given, and developers who flout it don't deserve to have databases.
Other points are bellwethers. If your organisation doesn't maintain an up-to-date Physical Data Model then it's likely most if not all of your tables are bad (not inevitable, just likely). It's astonishing how many places don't seem to keep their DDL scripts under source control. How do they manage their deployments to test and production? I think prayer features heavily.
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.
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
when it comes to SQL DB schema, is it a better practice to add more "boolean" like fields or is it better to keep one field and have it be "mode" representing different combinations? For either case, can you elaborate why it's better?
Thanks
If you care about specific values of things . . . IsActive, IsBlue, IsEnglishSpeaking, then have a separate flag for each one.
There are a few cases when having a combined "mode" might be beneficial. However, in most cases, you want your columns to represent variables that you care about. You don't want to have special logic dissecting particular values.
In MySQL, a boolean value actually occupies 1 bytes (8 bits). MySQL has other data types such as enums and sets that might do what you want. The bit data type, despite its name, does not seem to pack flags into a single byte (which happens on other databases).
I think I get where you're coming from... The answer is: use boolean for has_property scenarios, and something else for everything else.
Basically, you're talking about a "flag" versus a "variable". Flags are boolean. Everything else has some other type (integer, datetime, etc...). Databases have strict typing, so either work with a strictly typed language or make sure the data you pass to you DB is correctly typed. DBs have incredible flexibility, as well. For instance, BLOBs can store arbitrary binary data (like pickled Python).
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.
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 8 years ago.
Improve this question
I am working on a system that can create made up fanatsy words based on a variety of user input, such as syllable templates or a modified Backus Naur Form. One new mode, though, is planned to be machine learning. Here, the user does not explicitly define any rules, but paste some text and the system learns the structure of the given words and creates similar words.
My current naïve approach would be to create a table of letter neighborhood probabilities (including a special end-of-word "letter") and filling it by scanning the input by letter pairs (using whitespace and punctuation as word boundaries). Creating a word would mean to look up the probabilities for every letter to follow the current letter and randomly choose one according to the probabilities, append, and reiterate until end-of-word is encountered.
But I am looking for more sophisticated approaches that (probably?) provide better results. I do not know much about machine learning, so pointers to topics, techniques or algorithms are appreciated.
I think that for independent words (an especially names), a simple Markov chain system (which you seem to describe when talking about using letter pairs) can perform really well. Feed it a lexicon and throw it a seed to generate a new name based on what it learned. You may want to tweak the prefix length of the Markov chain to get nicely sounding results (as pointed out in a comment to your question, 2 letters are much better than one).
I once tried it with elvish and orcish names dictionaries and got very satisfying results.