Re: Migrating database field values rules from Perl code to DB

Well, maybe there's more to it than I wrote originally.

I imagine a Perl script with some generic form generation routines that take their directions from some specs held within the database.

For example, for field_1:

at creation is to be displayed as a drop-down on the creation screen, with possible values a-to-z,
not be editable on a record-update screen
in a listing of records from the table, not be displayed if the user is of user_type=X.

These parts of the database specification are going to be littered here and there throughout the system, in conditionals and template layouts. What I imagine is having these specs centralized within the database somewhere and then a generic screen form element generator script that takes its direction from those specs.

Mmmmmm....I'm beginning to imagine a table of table column specs.....

Table: specs
table_name, field_name, creation_form_type, editable, view_types,....
[download]

Something like that....but I fear a great deal of querying for every page generation.

Forget that fear of gravity,
Get a little savagery in your life.

Comment on Re: Migrating database field values rules from Perl code to DB Download Code

Replies are listed 'Best First'.
Re^2: Migrating database field values rules from Perl code to DB by dragonchild (Archbishop) on Feb 12, 2007 at 17:20 UTC
Any time you want to start putting application constraints into a database, you should stop thinking and just do the simplest thing possible. That will, most likely, not involve a database. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^3: Migrating database field values rules from Perl code to DB by ptum (Priest) on Feb 12, 2007 at 18:47 UTC
I respectfully disagree with this assessment. While it is certainly true that you can overcomplicate your application for the next poor guy who has to maintain it by storing all kinds of application logic in a database, there are a couple of good reasons for storing allowable field values and other application configuration data in a database table or tables. Such reasons may include: The entry field in question may appear in multiple locations throughout the application -- storing (and retrieving) constraints like this may save you from some ugly (and difficult to maintain) duplication of code. You expect the allowable values for some of the fields to frequently change over time, and you'd like to avoid multiple trivial releases of your code. Updating your code in production is fraught with red tape; in some corporate environments, database changes can often sneak under the wire, avoiding onerous (but unsophisticated) bureaucratic constraints. You have a very large number of entry fields with a large number of similar attributes, and you want to simplify your application code. You need to be able to re-configure your application on the fly in a distributed environment. I'm sure there are more reasons than this, but these are a few which come to mind, suggesting that the advice dragonchild offered above is not universally true.	[reply]
Re^4: Migrating database field values rules from Perl code to DB by dragonchild (Archbishop) on Feb 12, 2007 at 19:37 UTC
The entry field in question may appear in multiple locations throughout the application -- storing (and retrieving) constraints like this may save you from some ugly (and difficult to maintain) duplication of code. You have a very large number of entry fields with a large number of similar attributes, and you want to simplify your application code. This is what configuration files coupled with useful abstractions are for. This is not what a database is for. You expect the allowable values for some of the fields to frequently change over time, and you'd like to avoid multiple trivial releases of your code. Changing the allowable value of a field is NOT a trivial release. If you allow a value that goes over an edge case, then you have introduced dirty data. Dirty data is almost always impossible to get out. You need to be able to re-configure your application on the fly in a distributed environment. This is the ONLY relatively sane reason to put application logic into a database. And, there are much better ways of accomplishing the same thing. The only thing a database brings to the table is the centralization. Centralized datastores aren't necessarily a full-on RDBMS. For example, a simple DBM::Deep or BDB file on a NAS would be perfectly fine for things like this. And, I've saved the best for last ... Updating your code in production is fraught with red tape; in some corporate environments, database changes can often sneak under the wire, avoiding onerous (but unsophisticated) bureaucratic constraints. Allow me to rephrase: "Because my company actually respects change control, I will exploit a loophole in order to avoid actually managing my changes. Instead, I will unleash changes unto prod in a lone-cowboy fashion." Change control exists for a reason. Often, it's because you do NOT understand the ramifications of your changes. Furthermore, even if your bureaucracy should be avoided, you are breaking your application design. Assuming that this is a good plan, it is a consequence and not a reason. It's like saying "Eating a bowl of sugar is good for my health because it's better than eating a bowl of lard." My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^5: Migrating database field values rules from Perl code to DB by ptum (Priest) on Feb 12, 2007 at 20:58 UTC
Re^6: Migrating database field values rules from Perl code to DB by dragonchild (Archbishop) on Feb 12, 2007 at 21:32 UTC
Re^3: Migrating database field values rules from Perl code to DB by hossman (Prior) on Feb 12, 2007 at 21:02 UTC
if the discussion is about putting code in your DB that apps should SELECT out and then run arbitrarily, I'd agree with you on moral grounds -- but there are lots of situations where the "data" for one application is "constraints" for another application. CMSs are a great example of applications where the person writing the application doesn't know what kinds of constraints the end user needs for their data, because the "content" is different for each installation -- so the "adminstrators" of the system enter the constraint data, and the "users" of the system enter the content that conforms to those constraints. Surely you wouldn't suggest that everyone who wants to install/maintain a complex application needs to write code to define how they wnat to allow others to use that application? you might rgue "that's what configuration files are for." but how is puting that information in a configuration file really any different then putting it in a database?	[reply]
Re^4: Migrating database field values rules from Perl code to DB by dragonchild (Archbishop) on Feb 12, 2007 at 21:24 UTC
That's an apples'n'oranges distinction. "administrators" of a CMS are users of that CMS. The developers are meeting their user requirements. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^5: Migrating database field values rules from Perl code to DB by hossman (Prior) on Feb 12, 2007 at 22:24 UTC
Re^6: Migrating database field values rules from Perl code to DB by dragonchild (Archbishop) on Feb 13, 2007 at 00:18 UTC