Main Area and Open Discussion > Living Room

Opinions on database items that can be provided otherwise ... ?

(1/2) > >>

barney:
OK, this is kinda dumb, but I need a think break  :P.

Some acquaintances and I have been having a discussion on database inputs.  I'm partial to using HTML select items for miscellany that, while important to the database app, do not have to be in a table.

For instance, if I'm listing a series of options, particularly if there can be multiple choice, I'll create a select with the available choices with binary values, e.g., 1, 2, 4, 8, 16, 32, ... .  They are hard-coded into the appropriate page/form, and it's easy to make additions when required.

The quarrel is that this data is not truly in the database until a value is selected, thus there is no source for it.  I can appreciate the concept, but at the same time, no call to the database is required to populate the appropriate select(s).

This discussion has been going on for a couple of months - the group involved is, while small, global - and some good points have been made on both sides of the issue.  I suspect this is one of those discussions that no one wants to win, but everyone seems to have a [rather fervent] opinion.

Given that, I'm curious what the folk here might think - and why  :tellme: - one way or the other.  (And, if you happen to be one of the group (yeah, I know, I just branded myself), please abstain from comment - this is a search for outside opinions  :P :P.)

Renegade:
It seems to me that the real question is whether or not the values would change in the database. If not, then why constantly make the same trip to the database to get the values?

You're just putting on addition overhead that isn't necessary.

Now, you could read from a static file, and that would be less overhead, but solve the problem. You just put a trigger in the database and write the new file whenever values change.

I don't like hard coding unless there's a good reason. But if it's something that isn't going to change, or if it is only going to change on exceedingly rare occasions where you are doing development anyways, then it can make sense to hard code. You avoid overhead. Granted, it's not likely much, but it could become important if you have many decisions like that to make. Many drops fills the glass.

However, I would want to have the information in the database anyways. I like domain constraints. They keep things neat and tidy.

Just my $0.02 anyways.

Stoic Joker:
I think it would depend on the intended use of the application. If it's an internal use only project, then shortcutting with a hard coded select is fine. In a pinch I've used a function to insert a select so in can be used in multiple places and only have to be edited in one.

But if it's going to be a released to the masses project, then hard coding anything makes it an inflexible pain in the neck for whoever is trying to get it dialed in for their specific purposes. There's just no anticipating the kind of crap people will think of to need... ;)

Renegade:
I think it would depend on the intended use of the application. If it's an internal use only project, then shortcutting with a hard coded select is fine. In a pinch I've used a function to insert a select so in can be used in multiple places and only have to be edited in one.

But if it's going to be a released to the masses project, then hard coding anything makes it an inflexible pain in the neck for whoever is trying to get it dialed in for their specific purposes. There's just no anticipating the kind of crap people will think of to need... ;)
-Stoic Joker (June 09, 2011, 06:36 AM)
--- End quote ---

Good points. That makes a massive difference.

40hz:
Been ages since I coded anything worthy of the name, but one thing we used to do for that type of semi-fixed data variable was to store them as plain text in a simple file. A small routine would read them in at program start. This gave it most of the advantages of hard coding and avoided the complexity of adding another table to our database. it also made the variables easy to find and change thereby eliminating a need to edit (and possibly screw up) the main program.

In one program we wrote, we used this 'method' for sales commission rates which changed very infrequently - but needed to be updated immediately when they did.

Using a flat text file, all we needed to do was backup a copy of the old file, edit it, and save it back.

Later on I created a spreadsheet so management could experiment with commission rates. When they were finished playing around, they could run a macro which exported the requisite file - and that was that. Sped things up dramatically, and got us off the hook since there was no way we could screw up an update because we no longer were responsible for keying in the data. Sweet! :up:

Note: don't know if it's still necessary to do it this way, but all our 'bushel basket' variable collections were stored as text. If a numeric value was required by the program, the loading routine would convert it to the proper numeric variable form. Doing it that way allowed us to mix & match text and numeric values in the same file. Most of our initialization routines got their values from this sort of 'init' or 'cfg' file.

 :)

Navigation

[0] Message Index

[#] Next page