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).
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 needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Started designing databases very recently. I am wondering if I chose the right data types.
For example, I was told to use integers for $ amounts to avoid troubles. Also for tax rates I put decimals, I assume I will have to convert it back to integer when calculated.
Thanks!
Database design:
Integers work great for integers, but not decimals. You can store pennies (or a thousandth of a penny) in an integer and then convert to to dollars when you display it in much the same way that we store dates as "seconds since 1st Jan 1970" but display them differently.
the trick there is to ensure your conversion always applies, and that's not so easy when using a common datatype like Integer.
DBs all have a decimal datatype that is fixed precision (NOT float or double) so use that and everyone will be less confused as to what it going on with a currency entry.
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 7 years ago.
Improve this question
Is there any mechanism for storing all the information of a probability distribution (discrete and/or continuous) into a single cell of a table? If so, how is this achieved and how might one go about making queries on these cells?
Your question is very vague. So only general hints can be provided.
I'd say there are two typical approaches for this (if I got your question right):
you can store some complex data into a single "cell" (how you call it) inside a database table. Easiest for this is to use JSON encoding. So you have an array of values, encode that to a string and store that string. If you want to access the values again you query the string and decode it back into an array. Newer versions of MariaDB or MySQL offer an extension to access such values on sql level too, though access is pretty slow that way.
you use an additional table for the values and store only a reference in the cell. This actually is the typical and preferred approach. This is how the relational database model works. The advantage of this approach is that you can directly access each value separately in sql, that you can use mathematical operations like sums, averages and the like on sql level and that you are not limited in the amount of storage space like you are when using a single cell. Also you can filter the values, for example by date ranges or value boundaries.
In the end, taking all together, both approaches offer the same, though they require different handling of the data. The fist approach additionally requires some scripting language on the client side to handle encoding and decoding, but that typically is given anyway.
The second approach us considered cleaner and will be faster in most of the cases, except if you always access to whole set of values at all times. So a decision can only be made when knowing more specific details about the environment and goal of an implementation.
Say we have a distribution in column B like:
and we want to place the distribution in a single cell. In C1 enter:
=B1
and in C2 enter:
=B1 & CHAR(10) & C1
and copy downwards. Finally, format cell C13 with wrap on:
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 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.