Re: Flexible DB Designs
- --- In agileDatabases@yahoogroups.com, patrickdlogan@a... wrote:
> > So as not to sound like a Pick/MultiValue evangelist, I'll use XMLNot exactly. Sharing data among different application is the essence of the coupling issue. If an application's data is completely private then there is no inter-application coupling. That is, if other applications need to make a request to the application, not to the data base server, then you've eliminated the coupling.
> > documents as an example of a means of storing data where the cost of
> > changing sizes of elements or cardinality is not so high (I
> > suspect). I don't have a lot of hands-on experience with XML
> > document-based data storage but perhaps when there is a need to make
> > changes to the type of data stored in an element or attribute, the
> > schema document could be modified, or a new one added, without a
> > need for a lot of other changes to the existing code (?)
> Flexible structures is part of the coupling issue. Another part is the
> language used to access and update the data. XML in general is a
> structuring language that does not in itself say anything about
> efficient storage mechanisms for access or update, nor does XML in and
> of itself say anything about expressive search or update behavior.
Language mismatch issues are examples of "impedance" mismatches. (I don't like the word, but I don't know of a better one.) The least mismatch is caused by a strategy that simply keeps all the data in objects in the application's process. That's simply not possible in the general case, but where it is, it works very well. (See Prevalyar for an example of how to do interesting things with it.)
Anything else causes a problem. The original hierarchical and network data bases and the not quite as old relational data bases are outgrowths of systems from the '60s and '70s, and have all of those assumptions built in.
> A language like Lorel...
> ...is a good example of the ability to "say less" about data in order
> to get to just what is desired. But the other end of the spectrum is
> the results become more ambiguous, i.e. including undesirable data or
> excluding desirable data.
> O/R mapping, object databases, deductive databases, and other
> techniques are also attempts to be more expressive about the behavior
> associated with persistent data without coupling too closely to the
> representation of the data.
> Relational tables are actually more general than hierarchical or
> network databases. The problem really is the languages that are used
> to access and update them. SQL is just too limited. I blame SQL more
> than the table concept per se.
- I have used a variation of they key-value idea successfully in the past.
We had a "keywords" facility that end users could use to mark a set of
records. (Then they'd do a "keywords search" to bring back all the
records marked with a given keyword.) We extended the facility to have
a special set of "system keywords", which were interpreted specially
by the program to accomplish flexible data tasks.
Our keywords weren't as sophistocated as key-value pairs though.
Basically, they denoted inclusion in a set. So you could, for example,
tag a bunch of people in the database as being on your "call today"
keyword. The system would just store a pair of integers -- the keyword
ID and the tagged record ID.
We were sometimes able to use this instead of adding boolean columns
to certain tables, which allowed us to extend the schema while
maintaining backward comatability. On one hand, it did make it a
little tougher to do queries, because you had to know about the
existence of this keyword in order to write your query. On the other
hand, since so many things were handled in the same way, it actually
made some queries a little easier.
This also made it easier for end users to write their own queries,
because they, too, had access to these system keywords. That's
something that may have been a little harder to flexibly implement if
all the data were stored in columns.
- Don't forget to that today all the data modification is through
the "APP" but tommorrow your app is sold to someone who has their
own XYZ module and wants to integrate directly into the database.
Hey you say how did the gender field get a "Y" in these records and
it's all downhill from there!
--- In agileDatabases@yahoogroups.com, "Bayley, Alistair"
> I think that you're going down a slippery slope if you replace your
> relational design (with integrity constraints) with a one based on
> pairs. Unless you are prepared to write a lot of code to enforethe business
> rules, and thus probably end-up writing a rule/constraint engine(and
> testing and maintaining it), you will lose the ability to enforcedata
> integrity. And if you allow all sorts of crap into your database,then you
> *get* all sorts of crap in your database.all of
> I think you're better off retaining a good relational design (with
> the protection that should give your data), and writing code tomigrate your
> data when the structures change. This *will* take less of yourtime then
> what you waste trying to fix problems caused by incorrect data inthe
> You may have a specific business requirement for key-value pairs
> example, the users must be able to create their owndescriptions/fields to
> attach to objects), but I think you should restrict that to justthe places
> where it is required.flexible, but
> Key-value pairs may make the database backwards compatible and
> if your application has no idea how to handle some of the datathen you will
> have problems. Again, you will also have to build data integrityrules into
> your application (and test them) rather than have them in thedatabase (they
> should really be in both but if you don't have them in thedatabase them
> you're asking for trouble).so
> -----Original Message-----
> From: mlovell98133 [mailto:m98133@h...]
> Sent: 21 November 2002 01:07
> To: agileDatabases@yahoogroups.com
> Subject: [agileDatabases] Flexible DB Designs
> I am interested in thoughts on building a flexible database schema
> that the database does not need to be restructured as thefor
> applications which use the database grow and develop.
> For instance, using property tables (with rows for a key, property
> name, and property value), rather than using a separate column for
> each property. This way as applications require more attributes
> entities, they can just add them to the database withoutkeep
> restructuring. It would also make the database backward compatible.
> What other techniques can be used to make a database flexible?
> Is it worth setting things up flexibly, or is it better to just
> rebuilding the database with new schemas? How do performance
> requirements effect the decision? What else effects the decision?
> The information in this email and in any attachments is
> confidential and intended solely for the attention and use
> of the named addressee(s). This information may be
> subject to legal professional or other privilege or may
> otherwise be protected by work product immunity or other
> legal rules. It must not be disclosed to any person without
> our authority.
> If you are not the intended recipient, or a person
> responsible for delivering it to the intended recipient, you
> are not authorised to and must not disclose, copy,
> distribute, or retain this message or any part of it.
- At 01:14 PM 11/4/2005, you wrote:
>Don't forget to that today all the data modification is throughYes, which might be why you want a test suite for your database. Got
>the "APP" but tommorrow your app is sold to someone who has their
>own XYZ module and wants to integrate directly into the database.
>Hey you say how did the gender field get a "Y" in these records and
>it's all downhill from there!
one of those?
Or, do you just have a bunch of models which the developers of XYZ
will likely never look at because they find the data group too slow
to respond to their requests for help?
Scott W. Ambler
Senior Consultant, Ambysoft Inc.
www.agiledata.org -:- www.agilemodeling.com -:- www.ambysoft.com
-:- www.databaserefactoring.com -:- www.enterpriseunifiedprocess.com