[Info-vax] Databases versus RMS

[Jan-Erik Soderholm]

JF Mezei wrote 2012-04-17 21:40:
> Jan-Erik Soderholm wrote:
>
>> One DBMS is not like every other DMBS. I have have had a Rdb database
>> "break" due to a simple power failure.
>
> Are there options which make a database more robust, but many database
> admins, being too inexperienced, don't think about them ?  or are some
> database systems, being "free/opensourced" just too easy to get majorly
> screwed up because of a power failure ?
>
> (Yes, I do intend to find out what tht web forum uses and what sort of
> indexing technooogy it uses so I know NOT to use that).

Or use it properly. It can be a missuse of a perfectly good product.

>
> I just find it odd that datbase systems, designed to protect your data
> in a better way than ormal indexed files seem to not be so robust after all.
>

You can end up on the side of the road no matter how
"safe" you particular car is. Means nothing...

> I am moving an RMS/All-in-1 application over to my mac using mysql, PHP
> and HTML. And it appears one can set up a mysql datbaase without any
> locking, and some of the indexing seems very primitive (there are
> different indexing engines).

Depends on which engine you select, but yes, IMHO, MySQL is far
more primitime then, say, Rdb.

>
> I can understand one or two records being corrupt because an update was
> only half written,  but should that prevent the rest of the database
> from running ?
>

How "half written" ? Why?
>
>> And, generaly speaking, Rdb is more "safe" then a plain RMS
>> based "database".
>
> An RMS write tends to result in an immediate physical write to disk.
> (unless hidden by a storage array which delays writes).

So does e.g Rdb, to the transaction log at least. Actual data can be
delayed to disk. No problem at all, it's rolled forward from the log
in the case of a power failure.

>
>
> The reason I am askig is to know whether the "industry" has accepted
> those risks of hiding physical disks behind storage arrays that may not
> write right away and behind database engines that not only delay writes
> and cache stuff on their own, but can also get corrupt because of a
> power failure.
>

I do not think you know fully what you are talking about. It's a bit
hard to understand what scenario you are describing. There are way
to may parameters here to say anything about this.



>