ElevateDB relational model do’s and dont’s

Question

My company uses ElevateDB in one of our products. However, our database is just a bunch of tables. Recently, as more features are designed and more modules are added, we have found out our data is no longer “bunch of unrelated tables”, but it begins to be real data structure.

I have no previous experience with ElevateDB, I worked with Oracle, MSSQL and Firebird mostly. So the question is – if we want to restructure table structure to have foreign key constrains and implement relational integrity, what are common pitfalls on ElevateDB? I am not asking about general issues on relational databases, but I am interested in ElevateDB do’s and dont’s.

We are using Delphi 2009 as a client application.

Answer 1

The only thing that may trip you up with RI in ElevateDB is the lack of cascading updates or deletes. We leave those up to the user to handle with a transaction (you can also use triggers to do so). No matter what, ElevateDB will always still enforce the RI and prevent any improper data in terms of primary and foreign keys. Essentially, ElevateDB's RI only supports the RESTRICT option for the ON UPDATE and ON DELETE clauses.

If you have any other questions, feel free to ask them on our newsgroups at the URL mentioned above by Stuart.