Houghton,Andrew wrote:
>
> In addition, any current SQL database can deal with semi-structured
> data without the use of XML columns or full text indexing through
> the use of stored procedures and/or business logic to shred the
> semi-structured data into a relational form.
Yes, but what about performance? [I know, buy a bigger machine and
larger disks...]
>
> You cannot display a SQL index since it is an internal mechanism
> that is used in relation to the data stored in the tables in your
> database. This doesn't mean you cannot support "index browsing".
>
But why do so many SQL-based applications not do it?
>
>>Further, SQL doesn't support structured fields. A field
>>content cannot have subfields, or rather, SQL has no tool to
>>do anything with them.
>
>
> This is just not true. Lets take the MARC standard. Each field
> has a one to many relationship with its subfields. In a relational
> database this *could be* modeled with two tables.
Yes, it "could". Again, this must in many cases be ruled out because
of inefficiency and the sheer bulk of the tables you end up with.
>
> This may not be the best database architecture for modeling MARC in
> a relation database,
Sorry, but shouldn't "next generation" be aiming at the best, and
not compromise using inappropriate standards (just because they are
standards)?
> Again, a relational database can contain keyword indexes either
> through full text indexing a column or using appropriate business
> logic and/or a stored procedures to shred the information and
> store the data in a table.
>
Again, who does it, and why not?
>
> Not saying that would be the best approach... but it might invoke
> that 80-20 rule where using a relational database is good enough.
>
"Good enough" is, but I may be overly ambitious, not "next generation".
B. Eversberg
Received on Wed Jun 21 2006 - 06:13:53 EDT