For my application I need to keep the prefered unit of measurement of a user.
The possible units currently are:
Liter (the unit the values in the rest of my database are stored in)
Kilogram (varries with the density of the products)
US Liquid Gallon (3.785411784 litres)
US Liquid Quart (1/4th of above)
UK Liquid Gallon (4.54609 litres)
UK Liquid Quart (1/4th of above)
I need a way to save these units in an mssql 2005 (and up) database so that there can be no ambiguity and preferably without all the applications keeping an enumeration and without having to create an extra table.
Using an ISO abbreviation would work for the first two, but AFAIK there is none for the last four.
Using the string representation is also asking for trouble..
So besides of finally getting through to the project manager about not using retarded units of measurement, what other suggestions do you have?
I know you don't want to create a new table, but in all honesty, it's the Right Thing™ to do. Add a column with a foreign key reference, and just do it - it'll work better in the end!
I think you need to reconsider using a table to store these values. The main reason being that you will want to convert from one unit of measure to another and you need to decide on the number of significant digits that is important to your application.
If you have a table, then you can store the litre to X conversion value in the record. This will help keeping all of the other applications in sync in order to reduce rounding and comparison problems.
Related
I'm working on an application that saves phone numbers, the mask for the phone number is (99) 9999-9999.
Should I save the whole string on the database. i.e.:
(99) 9999-9999
or just the data i.e.:
9999999999
and only format it in the UI?
I'm leading towards the second one but I couldn't give good reasons on why is that. My coleague argument was that the first one (the one with the mask) would be easier, since it's not necessary to apply the mask in different UIs (reports, webpage).
Separate data and presentation logic - this is good practice.
I suggest you to store only number, as number is data, and formatting is not (store only data in database).
Second, maybe for this moment you have 1 format, but believe me - in some time you will need another format and then you will have to re-format it (some kind of murphy's law)
Of course, for performance reasons you can cache visual presentation - create additional field(s) for it and use it for display, update it when main "data" field is updated
I need to design a database table where most attributes have units. For example:
Readings
--------
id load (kW) fuel_consumption (tonnes) - etc
1 1154 89.4
2 1199 54.2
What's the recommended way to capture the units in the design? For example, I could:
store units within attribute names e.g. load_kW and fuel_consumption_tonnes
store units in a separate table e.g. each value becomes a foreign key to another table with columns for value and unit.
store outside the database: e.g. in business logic, or in documentation
are there others?
I happen to be using MySQL, but I assume this is a generic database normalisation problem.
Interesting question...
There are two obvious routes:
id load_kW fuel_consumption_tonnes
--------------------------------------------------
1 1154 89.4
2 1199 54.2
This is easy for humans to read, and fairly logical. However, if some readings are in "kilos", others in "tonnes", you have to convert those readings to fit into the "readings" table; this process MUST be "lossless", and idempotent. For instance, a reading of "89403 kilos" is not "89.4 tonnes", even though the business may choose to round from kilos to tonnes for convenience. There are usually some counter-intuitive rounding things that happen...
If that's the case, you could change the schema:
id load load_unit fuel_consumption fuel_consumption_unit
--------------------------------------------------
1 1154 kW 89403 kg
2 1199 kW 54.2 t
With a "unit" table, if you need it:
unit_id unit_name
--------------------
kg kilogramme
t Tonne
However, this model is open to human failure - it would be easy to change the "load_unit" column without modifying the "load" column, thus breaking the data. There's nothing you can really do to your data model to avoid this. It also makes common queries fairly tricky: imagine trying to retrieve the total of "load" in a consistent unit of measurement.
I would recommend that in this case, you have two tables: "raw_readings", with the original data in the format above, and "normalized_readings", which you populate by converting all the readings to a consistent unit of measurement.
It depends ultimately on what you intend or need to do with your quantities.
If (in the unlikely case) all you will ever do is record the values for later regurgitation, then it doesn't really matter what you do with units, since the scalar values have no semantic significance to your model.
It is much more likely to be the case that the scalars in your system have some importance to your system. This could be because you are performing calculations on them for example. In such a case your units matter very much.
The next question you need to answer for yourself is whether the units will always be consistent and must not be allowed to be changed. In most cases I would say that this is a risky conclusion. It could be a business rule that you impose through your system, but business rules have a nasty habit of changing.
For this reason I would recommend storing a unit of measure with every scalar that represents an actual measurement. Being explicit in this way takes a bit of disk space, but it gives you clarity and flexibility.
Something that I have done in the past is to extend the unit of measure model to include UOM types, like length, temperature, volume, time, etc. Keeping a table that maps each UOM to a UOM Type allows you to also store conversion factors. That way, if someone should come to you with a reading in BHP and pounds you would know what to do with it and how to compare it to your typical entries in kW and tonnes.
I need to use a percentage in my Rails app. In any view, including when it is entered by the user, the format will need to be the hundreds format, 100.000. When it's used in calculations, it needs to be represented in the hundredths format, 1.00000.
My migration (I'm adding the column to an existing table) has the following line:
add_column :worker, :cash_split, :decimal, :precision => 6, :scale => 5
So, as of right now, I'm storing it in the hundredths (1.00000) format. My basis for choosing to store it in this format is that i figure it will mean cleaner business logic (i.e. no worker.cash_split / 100.0.to_d code hanging around) when i need to do multiplication.
My only other thought was maybe abusing the composed_of method. I could store the data in the hundreds (100.000) format as cash_split and then make an attribute accessor cash_split_percentage that returns cash_split in its 1.0000 format counterpart.
Your first thought is the right one...don't overthink it.
You should definitely store percentage numbers in the database in hundredths format. And use that format in all of your Ruby calculations.
Percentage figures are a display convention. Eg the number 0.45 is displayed as 45%. As such, use a View helper to convert your percentage figures from their internal format (decimal numbers) to your chosen display format--a string which includes the % sign.
It depends.
First off, I don't think there is a right way or a wrong way. It's your app and your code, so you can do what you want, but you should do what makes the most sense for your circumstances.
As #BishmaStornelli commented in #LarryK's answer,
How would you handle percentages in forms? Users will want to enter it like 45% but it should be stored as 0.45. Nevertheless, if the user inputs another field wrong and the form is re-rendered, the percentage field sould have 45 and not 0.45. With this I want to say that a callback may not be the final solution.
You're damned if you do and you're damned if you don't. You either clutter up your calculation code with divisions by 100, or you clutter up your Model and Views with converting from a decimal to a percentage and back again.
I suppose the answer depends on which is more heavy in your application.
If you are conducting lots of calculations based on this percentage then storing it as a decimal would seem like the best approach that will provide the least amount of code and the clearest, cleanest code to view and maintain.
However, if you are not conducting lots of calculations based on this percentage (maybe only a couple) then it may make more sense to not have to write a bunch of code in the Model and Views to display the decimal as a nice percentage, and just divide by 100 when you need to perform a calculation.
In our particularly case, and the reason I ended up here, we want the User to enter the value as a nice percentage, like 75%, in the form. And we always want to display this value in Views, Reports, etc. as a nice clean percentage, like 75%. And we only need to perform a calculation with this value a couple of times.
So, it makes sense in our case to store the value as a percentage in the database. It makes saving and viewing much easier, and only incurs a "divide by 100" penalty in the couple of spots we perform a calculation on it.
Hopefully, that helps others and provides a different viewpoint to the already well-written and accepted answer.
Thanks #BishmaStornelli for the alternative perspective!
I want to store a standardized set of information about when a business is open for each day of the week. Is there a standard way to easily store/alter this in MySQL?
Thanks!
Database design is really an art, there are many different ways to design schemas.
I would start with a table, say "business_hours", and make the following columns:
- business_id (integer, auto increment)
- business_name (varchar, largish like 255)
- open_monday (varchar, integer, however you want to represent the data.)
- close_monday
repeat pattern of the last two columns until Sunday.
That's one way to do it, it's not a very sophisticated way, but it will work. Because I don't fully understand your context (i.e. what's using it, who's looking at it), it may be slightly off.
To me it seems like this might actually be better accomplished via html. Assuming the hours are very standard and won't change often it might just be easier to code them in with out making a sql table or database for these store hours. Now if they change a lot and are dependent on time of year, whether, or they change based on what the company is doing at the time then its probably easier to go the database route. If this is the case SamT has provided the answer as to how to catalog and store it.
I am stuck between row vs columns table design for storing some items but the decision is which table is easier to manage and if columns then how many columns are best to have? For example I have object meta data, ideally there are 45 pieces of information (after being normalized) on the same level that i need to store per object. So is 45 columns in a heavry read/write table good? Can it work flawless in a real world situation of heavy concurrent read/writes?
If all or most of your columns are filled with data and this number is fixed, then just use 45 fields. It's nothing inherently bad with 45 columns.
If all conditions are met:
You have a possibility of the the attributes which are neither known nor can be predicted at design time
The attributes are only occasionally filled (say, 10 or less per entity)
There are many possible attributes (hundreds or more)
No attribute is filled for most entities
then you have a such called sparce matrix. This (and only this) model can be better represented with an EAV table.
"There is a hard limit of 4096 columns per table", it should be just fine.
Taking the "easier to manage" part of the question:
If the property names you are collecting do not change, then columns is just fine. Even if it's sparsely populated, disk space is cheap.
However, if you have up to 45 properties per item (row) but those properties might be radically different from one element to another then using rows is better.
For example taking a product catalog. One product might have color, weight, and height. Another might have a number of buttons or handles. These are obviously radically different properties. Further this type of data suggests that new properties will be added that might only be related to a particular set of products. In this case, rows is much better.
Another option is to go NoSql and utilize a document based database server. This would allow you to set the named "columns" on a per item basis.
All of that said, management of rows will be done by the application. This will require some advanced DB skills. Management of columns will be done by the developer at design time; which is usually easier for most people to get their minds around.
I don't know if I'm correct but I once read in MySQL to keep your table with minimum columns IF POSSIBLE, (read: http://dev.mysql.com/doc/refman/5.0/en/data-size.html ), do NOTE: this is if you are using MySQL, I don't know if their concept applies to other DBMS like oracle, firebird, posgresql, etc.
You could take a look at your table with 45 column and analyze what you truly need and leave the optional fields into other table.
Hope it helps, good luck