Welcome Guest.   Make a donation to an author on the site September 02, 2014, 11:55:24 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
The N.A.N.Y. Challenge 2012! Download dozens of custom programs!
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: Opinions on database items that can be provided otherwise ... ?  (Read 1268 times)
barney
Charter Member
***
Posts: 1,242


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« on: June 09, 2011, 12:11:00 AM »

OK, this is kinda dumb, but I need a think break  tongue.

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  tongue tongue.)
Logged

Make a good day ... barn
Renegade
Charter Member
***
Posts: 11,204



Tell me something you don't know...

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #1 on: June 09, 2011, 12:24:05 AM »

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.
Logged

Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker
Stoic Joker
Honorary Member
**
Posts: 5,218



View Profile WWW Give some DonationCredits to this forum member
« Reply #2 on: June 09, 2011, 06:36:38 AM »

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... Wink
Logged
Renegade
Charter Member
***
Posts: 11,204



Tell me something you don't know...

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #3 on: June 09, 2011, 06:42:44 AM »

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... Wink

Good points. That makes a massive difference.

Logged

Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker
40hz
Supporting Member
**
Posts: 10,648



see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: June 09, 2011, 10:14:46 AM »

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! thumbs 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.

 smiley


« Last Edit: June 09, 2011, 06:36:06 PM by 40hz » Logged

Don't you see? It's turtles all the way down!
barney
Charter Member
***
Posts: 1,242


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #5 on: June 09, 2011, 11:02:45 PM »

Good points, all.  My personal approach, i.e., not client dictated, is to create a function, then load that as needed.  Not much different than a flat file, but normally only accessible by a developer, so to speak  Grin.  Granted, it's not an appropriate commercial approach, for the most part, but it serves me well in lesser circumstance.
Logged

Make a good day ... barn
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.042s | Server load: 0.1 ]