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.
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.
The community reviewed whether to reopen this question 20 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've read the MySQL Documentation on them, but still not clear on the benefits of Stored/Virtual Generated Columns? What are the pros/cons over storing the same data in an actual column and indexing that into memory? What are the pros/cons, and the best times/examples to when using them are more efficient or better?
Thank you!
A good reason to use a stored generated column is when the expression is costly enough that you want to calculate it only when you insert/update the row. A virtual generated column must recalculate the expression every time you run a query that reads that column.
The manual confirms this:
Stored generated columns can be used as a materialized cache for complicated conditions that are costly to calculate on the fly.
Besides that, there are some uses of generated columns that require the column to be stored. They don't work with virtual generated columns. For example, you need to use a stored generated column if you want to create a foreign key or a fulltext index on that generated 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 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 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 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 have a program that captures many different types of structured messages. I need to persist the messages to database. What is the forum's view on design and performance, between:
(a) using one big table for all message types, so to handle any new message type, new columns are added to the big table. So the database is one table that may end up having 100's of columns.
(b) using a tables for each message type, so for a new message type, a new table is added to the database
By performance I mean in terms of searching all messages (i.e. searching one table versus a search across joined tables) and in terms of development work (i.e. knowledge transfer between developers) and maintenance (i.e. when something goes wrong).
This sounds a bit like it's about normalisation, but I am not sure it is.
Thanks!
If I read you right, choice (a) amounts to what is called the "One True Lookup Table" (OTLT). OTLT is an antipattern. You can research it on the web.
Performance is degraded because the lookup has to be done on two fields, the type and the code. With separate tables for each type, the lookup is just on the code.
Queries are more complex, and therefore more likely to be in error.
Data management is harder if you want separate entry forms for each type. If you are going to have just one true type entry form, you need to be careful when entering new lookup values. Good luck.
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.