Eric Maryniak wrote:
< ... >
> Personally I feel that the question of performance <--> some
> features is partly philosophical: it depends on the relative
> importance you give to performance vs. eg. referential integrity.
> Imho you never let it come to a ref.int. violation in your
> front end apps, because you don't want to confront a user with
> that error---you'll usually write some (PHP eg.) procedures
> that will consistently insert, update or delete an object and
> related objects (or refuse to after precondition checking that
> will usually be more complex than a simple ref.int. check).
> And the openness and programmability (and fast) is an extra+.
> It's a real "programmer's database", i think.
> 1. No Sub-selects, which is very awkward, but can be surpassed in www
> applications, but they will be more complicated and will have more
> unnecessary fault possibilities and become bigger.
That's true, but most Subselects can be done with Joins , which mysql supports.
Subselects are on the way for the next major release. If you want to make a long term
decition, you can wait for this (will come
> 2. Transacties, foreign keys, stored procedures, triggers en commit
> rollback are not supported. In other words referential integrity is not
> supported. Because the NIWI databases are primarily meant for (online)
> input and mutation of records this is a very fundamental problem.
> In fact NIWI doesn't do anything else as (online) transaction
> For instance how to maintain a multithesaurus database that is used to
> index several objects in the databases without referential integrity
> implemented in the database engine.
Sorry, but you can use referential integrity with mysql. What you don't have is an
automatism for checking it. Your input programs
should never cause any violations, so why do you need checking for them? Checking will
only help developing this program.
Transactions is another issue. Sometimes a rollback can be useful. But if there is a need
for it, you can implement it yourself. I
personally made 3 bigger projects without needing transactions. They work without
> 3. No views make life very complicated.
If you have subselects views are not necessary.
The only real advantage of views is to allow granting priviledges on row basis.
> Conclusion: MySQL is a possible candidate (if it can search better and
> faster) to replace the NIWI search engine software PLweb.
You can bet on that!
> Because the
> data are stable. But that means unnecesarry replication of data.
> Nicer would be of course a direct web interface to the database in which
> the data are maintained.
> Online database applicaties become unnecesarry heavy and unreliable.
> Which is shown in the suggested solution for the deleting of
> mother-child related records on page 240 of the manual. Here the mother
> is killed before the children are removed. In case of problems there
> will be no way to find the children because the motherrecord is already
Sorry, but deleting the mother before the children is bad programming style nothing else.
And you always can check for children with no existing mother with a LEFT JOIN.
> In a good database I have only to implement refential integraty once
> when designing the database and that is independant of the application
> for which I use the database.
False you have to obey the referential integrity while programming. If you don't your
program will always fail with an DB error.
A FOREIGN KEY definition doesn't prevent you from programming wrong INSERT's.
The only thing triggers can do for you is an 'on delete cascade' that's all.
> Kind regards,
> Eric Maryniak
I hope it doesn't sound like flame.
This is my opinion. I got this by using MySQL and Oracle.
Yours may vary.