Just a question ive got to address with regards to limitations of current database technologies/practices in an application area such as online booking systems or online shopping systems

all i can come up with so far is query speed limitations due to referencial intergrity (if it is implemented) and storage of increasing amounts of data (also slowing the system down)

any ideas?

There are quilte literally millions of possible limitations that impact design decisions, but without a better understanding of your question it is almost impossible for me to figure out how to help you. Please either rephrase or better define your question.

-PatP

I guess this is homework in which case it's supposed to be your own work.

What do you think are the limitations of referential integrity in today's DBMSs?

its not "homework" in the sense you might be thinking of

its more a research area, so im baisically looking for direction

by referential integrity limitations i was refering to complex sql queries being slower due to joins along with them being more complex

the question is literally: address some limitations of database techniques/concepts and practices that are used within a certain application area' (i just supplied 2 of the possible application areas)

let me address both of these points after suggesting that database technologies don't have "limitations" in these areas nearly as much as those ideas you came up with

1. if you fail to implement relational integrity, you risk having bad data, and lemme tellya from over 35 years personal experience in information technology, users would rather have correct answers a little more slowly than wrong answers real fast (to say nothing of the increased development time as you attempt to do with application code what the database could be doing for you automatically)

2. if you can have a functional database application without storing increasing amounts of data, then you're really onto something -- just don't store any more data, and bob's your uncle

It seems to me that one of the principal limitations of SQL DBMSs is that they generally have inadequate or completely lacking support for referential integrity, multi-relvar constraints and constraints generally. Despite Rudy's apparent confidence I suspect that even in his databases (like many of mine for that matter) he is forced to compromise by not implementing many important constraints that ought to be present.

These are primarily logical and syntax issues but performance may also be a consideration. For example most of the leading DBMSs can't properly support constraints that are mandatory "in both directions", can't handle N-cardinality rules efficiently or at all and have no straightforward way to set up inclusion dependency or join dependency constraints. Furthermore, even where some workarounds might be available, the query optimisers in those products can't take advantage of such constraints to allow query re-writes and other optimisations.

Lack of integrity support is one of SQL's biggest failings - as evidenced by the number of products that have grown up to solve data quality problems and implement business rules in databases.

well my thinking behind what i said was under the impression that a different more effective approach might be to look at object relational database concepts (i believe the newer versions of oracle support these ideas)

another thought i had was discussing distributed databases, in terms of the different types of fragmentation that might help improve certain existing limitations (if not already used)

Poor performance is usually more a combination of poor db design, poor indexing and crappy SQL - it's rarely anything inherently wrong with the RDBMS.

Handling searches on text fields where the word your searching for could be anywhere in the text is also difficult especially if the word is also misspelt.

Handling tree structures (say for product lines etc) is usually poor in most RDBMS systems.

Recording a history of change on records is also poor - it usually needs to be done manually and involves lots of compromise.

The biggest issue in my eyes though is maintenance - making any changes to the structure of a live database is always painful.

Object Relational means the same as Relational, ie: the database supports types of arbitrary complexity. In principle I think the integrity constraint mechansim ought to be similar irrespective of type but there are probably limitations as to what can be indexed.

Or maybe you had in mind the idea of using object IDs and pointers in place of referential constraints. I don't believe that has any conceivable benefits but it has many and well-known disadvantages.

hm

yeah i was refering to object ids and pointers

from what ive been taught i was under the impression that in general this is the way databases are 'moving' as the object relational concept allows for inheritance and polymorphism

with regards to the OID's and pointers, my understanding is these simplify the process of table joins e.g.replacing a previously very complex set of joins and still obtaining the same results

DBMSs with richer type support is certainly a trend and an all-round good thing. It doesn't fundamenally change the nature of a relational or SQL database though. Features like inheritence and polymorphism are just properties of the underlying type system on which the database is built and the relational model has always been agnostic about what data types actually get used within it.

OIDs and pointers are a different matter. The Relational Model was designed to banish pointers, addressing and other navigational structures precisely because of the serious limitations of those structures in systems that historically used them. The benefits of doing so include increased flexibility (you aren't limited only to pre-defined navigational paths), improved physical data independence and more options for optimising the database. The RM is also a mathematically based model, which makes it possible to analyse, derive solutions and prove correctness in that model.

Don't think about changing the model as a way of improving performance. Performance is ultimately determined by the way the model is implemented in software and hardware. I've already mentioned a few limitations of the current implementations.