On Sat, Apr 08, 2006 at 05:53:46AM -0500, [EMAIL PROTECTED] wrote: > > [EMAIL PROTECTED] wrote: > > > > On Sat, Apr 08, 2006 at 05:16:56PM +0800, Lars Hansson wrote: > > > On Saturday 08 April 2006 01:08, [EMAIL PROTECTED] 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
