Re: complex data structures in cells

From: Paul Brown <paul.No.brown_at_informix.com>
Date: Tue, 03 Oct 2000 11:38:59 -0700
Message-ID: <39DA27C2.94737352_at_informix.com>


tmac_at_transport.com wrote:

> Is it poor db design to dump complex data structures into cells?

  It depends. If what you're doing is plonking into the row/column cell something that appears, so far as the rest of the DBMS is concerned, like a BLOB, then it probably isn't a good thing. It makes it awakward to get it back out again, and to operate on the object in place.

  But if what you're doing is embedding both the object's structure and some logic implementing its behavior into the database then it can be very powerful. This approach--of making the data model extensible--is being pursued by most of the big DBMS vendors.

   For example:

 CREATE TABLE Customers (

        Name            Person_Name        NOT NULL,
        Address        Mail_Address         NOT NULL,
        Mug_Shot     Digital_Image         NOT NULL,
        CHECK ( Address.Country IN 'Holland','Belgium','Luxembourg')
  );

   and

   "Show me all train stations within 5 KM of where each of my female customers lives?"

    SELECT toString( C.Name ), toString ( S.Address )

       FROM Customers C, Train_Stations S
     WHERE Within ( S.Location, Circle ( Geocode ( C.Address ) , '5 KM'
) )
           AND Face_Gender ( C.Mug_Shot, "F" ) > 0.9;

    The key question revolves around the nature of what you're putting in the database. If it is simply a convenience for a host programming language, then it's probably not a good idea. But if it's something you can query on (and your DBMS allows it) then it can improve the performance and flexibility of your application.

    Hope this helps!

          KR

                         Pb
Received on Tue Oct 03 2000 - 20:38:59 CEST

Original text of this message