Loading ...
Sorry, an error occurred while loading the content.
 

Re: Flexible DB Designs

Expand Messages
  • jhrothjr <yahoogroups@jhrothjr.com>
    ... Not 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
    Message 1 of 13 , Dec 31, 2002
      --- In agileDatabases@yahoogroups.com, patrickdlogan@a... wrote:
      > > So as not to sound like a Pick/MultiValue evangelist, I'll use XML
      > > 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.

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

      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.

      John Roth
      >
      > A language like Lorel...
      >
      > http://citeseer.nj.nec.com/abiteboul97lorel.html
      >
      > ...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.
      >
      > -Patrick
    • drewivan <drewivan@yahoo.com>
      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
      Message 2 of 13 , Jan 6, 2003
        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.
      • johnc650
        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
        Message 3 of 13 , Nov 4, 2005
          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!

          -jfc-


          --- In agileDatabases@yahoogroups.com, "Bayley, Alistair"
          <alistair_bayley@l...> wrote:
          >
          > I think that you're going down a slippery slope if you replace your
          > relational design (with integrity constraints) with a one based on
          key-value
          > pairs. Unless you are prepared to write a lot of code to enfore
          the business
          > rules, and thus probably end-up writing a rule/constraint engine
          (and
          > testing and maintaining it), you will lose the ability to enforce
          data
          > integrity. And if you allow all sorts of crap into your database,
          then you
          > *get* all sorts of crap in your database.
          >
          > I think you're better off retaining a good relational design (with
          all of
          > the protection that should give your data), and writing code to
          migrate your
          > data when the structures change. This *will* take less of your
          time then
          > what you waste trying to fix problems caused by incorrect data in
          the
          > database.
          >
          > You may have a specific business requirement for key-value pairs
          (for
          > example, the users must be able to create their own
          descriptions/fields to
          > attach to objects), but I think you should restrict that to just
          the places
          > where it is required.
          >
          > Key-value pairs may make the database backwards compatible and
          flexible, but
          > if your application has no idea how to handle some of the data
          then you will
          > have problems. Again, you will also have to build data integrity
          rules into
          > your application (and test them) rather than have them in the
          database (they
          > should really be in both but if you don't have them in the
          database them
          > you're asking for trouble).
          >
          >
          > -----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
          so
          > that the database does not need to be restructured as the
          > 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
          for
          > entities, they can just add them to the database without
          > 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
          keep
          > rebuilding the database with new schemas? How do performance
          > requirements effect the decision? What else effects the decision?
          >
          > Thanks
          >
          >
          > *****************************************************************
          > 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.
          > *****************************************************************
          >
        • Scott W. Ambler
          ... Yes, which might be why you want a test suite for your database. Got one of those? Or, do you just have a bunch of models which the developers of XYZ will
          Message 4 of 13 , Nov 4, 2005
            At 01:14 PM 11/4/2005, you wrote:
            >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!


            Yes, which might be why you want a test suite for your database. Got
            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

            ====================================================
            Scott W. Ambler
            Senior Consultant, Ambysoft Inc.
            www.ambysoft.com/scottAmbler.html

            www.agiledata.org -:- www.agilemodeling.com -:- www.ambysoft.com
            -:- www.databaserefactoring.com -:- www.enterpriseunifiedprocess.com
          Your message has been successfully submitted and would be delivered to recipients shortly.