http://www.perlmonks.org?node_id=471917


in reply to Re^2: Perl Typeless Database
in thread Perl Typeless Autovivifying Database

I would not want any of my database programs to have a data collection average of even a Hall of Fame baseball player. A Ted Williams program, for example, would get its data less than 40% of the time.

UDP is, in of itself, unreliable. But programs using it are not necessarily so. Would you use unreliable NFS? I doubt it, but NFS uses UDP. But it also uses RPC, which has a request/reply protocol that allows for retransmissions should a reply not arrive within a specified window. Other UDP applications (e.g., video or audio streaming) may allow a certain level of loss because they know that some percentage of dropped packets will be undetectable by the human using the application. The key is that they have methods they can use within, or layered above, the UDP protocol (e.g., sequence numbers) that allow the receiver to monitor and detect the (un)reliability of the underlying UDP protocol.

Reliability/speed tradeoffs are acceptable for services but the (un)reliability has to be detectable.

Replies are listed 'Best First'.
Re^4: Perl Typeless Database
by tomazos (Deacon) on Jul 02, 2005 at 14:14 UTC
    All of this is true. I guess when I say reliability, I mean the extent to which a user or developer mistake or bug causes the system to fall over.

    Specifically talking about the database design. Say someone made a typo in the column name. The database would happily autovivify a new column for them. Same as in Perl if you make a typo in a hash key. A new entry is created.

    For some applications, such as prototypes or small systems, or simply systems that don't matter that much or have short lifetimes - this is an acceptable and reasonable tradeoff.


    Andrew Tomazos  |  andrew@tomazos.com  |  www.tomazos.com

      I see. Your goal makes sense. From a practical view, as an Oracle user, I find that me automatically doing things DBA's consider their realm (creating tables, assigning primary keys, creating indices) hasn't gone over so well. Some of that is due to bugs in Oracle -- e.g., once I auto-analyzed a table as it was being used and crashed the entire database. I'm not saying this "don't touch" view is necessarily correct, but it does exist in my world.