januserrornet.de
Date: Sat Apr 08 2006 - 07:01:58 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sat, Apr 08, 2006 at 05:53:46AM -0500, TonyServaCorp.com wrote:
>
> januserrornet.de wrote:
> >
> > On Sat, Apr 08, 2006 at 05:16:56PM +0800, Lars Hansson wrote:
> > > On Saturday 08 April 2006 01:08, Tonyservacorp.com wrote:
> > > > If you made a field too short for some of the data which comes along
> > > > there are two different approaches as to how to handle the situation.
> > > > First is to identify the problem and roll back so that
> > nothing even got
> > > > started. This is what "real" RDMSs apparently do.
> > >
> > > Say what? A real RDBMS does not roll back transacations when
> > you failed to
> > > design your fields properly or when you modify a table.
> > >
> >
> > A real RDBMS keeps your well designed data consistent and safe, that's
> > the point.
>
> That looks like a completely accurate statement.
> (But what about all your data BEFORE it has been well designed etc?)
>

The question then should be ``Do i need the data in the state from
before and shouldn't be the tape backups enough?'' ;-)

> >
> > > > Second is to keep going and minimize the damage as best you can.
> > >
> > > I dont really understand what youre trying to say. Keep going
> > and minimize
> > > damage? How would you do that when your fields are too small?
> > And what has
> > > this got to do with PostgreSQl v.s mySql anyway?
> > >
> >
> > PostgreSQL HAS methods to help your data to be more safe... without
> > using other table types, replication or such workarounds. No flames,
> > just facts.
> >
> > > > This is what systems that face the "real world" are forced to do.
> > >
> > > Are you saying that "real" RDBMS' arent used in the real world?
> > >
> >
> > Superficality vs. thoroughness is what i see in the real world as well
> > as in this case.
> > As already read in other posts to this thread there are reasons for
> > superficality... even if i'm estimating it more as redundant work, but
> > that's really up to the people with the actual problem/solution.
> > I like to have a lot of work ONCE in a while without the need to care
> > about it for the next few decades.
> >
> > > > There was a crack in this about MySQL being an SQL-looking front end
> > > > to a file system. Actually very perceptive. You can use the filesytem
> > > > to move stuff around and get away with it very nicesly.
> > >
> > > Perhaps that is becuase mySql seems to be very often used as a
> > glorified
> > > replacement for flatfiles, especially by webdesigners.
> > >
> >
> > Doh... do we now talk about those who don't even known what they need a
> > SQL frontend for? Thanks... out of (my) context ;-)
> >
> > > > As to losing data, I suspect you'd lose a lot more
> > > > from PostgreSQL than MySQL on a failing hard drive.
> > >
> > > I seriously doubt that.
> > >
> >
> > But i second that. Assuming one's using referetial integrity,
> > definitely! More constistent data is more valuable data!
> Out of curiousity, how does referential integrity guard against
> damaged disks? What does the system do when you lose the things
> that the system guarantees have to be there?

I meant the actual lose of value... trying to imply that worked off data
is worth a backup ;-)

Just conclusions from a few years experience with both database systems.

Regards
Simon

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]