LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > LinuxQuestions.org > 2005 LinuxQuestions.org Members Choice Awards
User Name
Password
2005 LinuxQuestions.org Members Choice Awards This forum is for the 2005 LinuxQuestions.org Members Choice Awards.
You can now vote for your favorite products of 2005. This is your chance to be heard! Voting ends March 6th.

Notices

View Poll Results: Database of the Year
MySQL 660 62.98%
PostgreSQL 168 16.03%
Firebird 83 7.92%
Oracle 44 4.20%
Sybase 4 0.38%
DB2 16 1.53%
Berkley DB 10 0.95%
sqlite 59 5.63%
InnoDB 1 0.10%
EnterpriseDB 3 0.29%
Voters: 1048. You may not vote on this poll

Reply
 
Search this Thread
Old 03-06-2006, 05:26 PM   #106
Berhanie
Senior Member
 
Registered: Dec 2003
Location: phnom penh
Distribution: Fedora
Posts: 1,625

Rep: Reputation: 165Reputation: 165

Disappointing that the mob, which has only tried MySQL, dictated the outcome. Mais, c'est la vie!
 
Old 03-06-2006, 11:40 PM   #107
MacNugget
LQ Newbie
 
Registered: Mar 2006
Posts: 3

Rep: Reputation: 0
Berhanie has it exactly right. It's disappointing that the technically superior PostgreSQL which enjoyed not only a major release (8.0) but also a significant point release (8.1) during the year has lost out to a product which is more restrictively licensed, technically inferior, and which languished for nearly two years unable to pull a production release out of their 5.0 codebase and which still hasn't closed the feature and performance gap when compared to other more mature products. This discrepancy in voting apparently because there's a large, vocal majority of users who have never used anything other than MySQL.

One would have hoped that "...of the year" might carry more meaning than a mere popularity contest. I guess this means that Windows would win the LinuxQuestions operating system of the year as well, since the majority of users on the net have used nothing else.

Last edited by MacNugget; 03-07-2006 at 05:55 AM.
 
Old 03-07-2006, 08:38 AM   #108
jeremy
root
 
Registered: Jun 2000
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 10,376

Original Poster
Rep: Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620Reputation: 2620
MacNugget, that might be pushing it a little bit (the Windows comment). If you look back, PostgreSQL actually did win one year...if that's any consolation to you.

--jeremy
 
Old 03-08-2006, 06:54 PM   #109
James Day
LQ Newbie
 
Registered: Mar 2006
Posts: 3

Rep: Reputation: 0
Quote:
Originally Posted by decibel
Wikipedia is a good example... based on the data they've got posted about their hit rates they should be able to drive they entire site off a single PostgreSQL database, instead of the 7 MySQL servers they're using
I'm the first DBA for Wikipedia and the person who did much of the query optimisation and physical database design work as it scaled from one server to where it is now.

PostgreSQL for Wikipedia would be a disaster because it's so hugely inefficient and hence likely to be slow even if we threw a hundred times as many servers at the problem.

The problem is a fundamental design issue in PostgreSQL (and MyISAM in MySQL). It stores records in the physical order in which they were added and you can only change that with a slow batch operation. That can be a little inconvenient when you have hundreds of gigabytes of data.

By contrast, InnoDB has a massive performance advantage. The designer can choose the primary key and InnoDB will physically store records grouped by primary key. If you want PostgreSQL Style, just use autoincrement, if you want something else, choose that instead.

Wikipedia heavily exploits this to dramatically increase the speed of the queries it does.

Lets look at the PostgreSQL-type situation we had before we started doing that.

Records were stored physically in the order in which they were added. People add in effectively random order (not right and that matters for working set issues, but it'll do for this discussion). Take the revision history of an article. Summary info for the last 50 revisions. Some articles have tens of thousands of revisions and people can freely move through them.

PostgreSQL case: 50 revisions means 50 random disk seeks to get the records.

InnoDB case: 1 or 2 and the second would probably be sequential.

It's worse though. Now go back 30,000 revisions. PostgreSQL 30,000 random seeks. InnoDB, maybe 50-100, mostly sequential.

Before we optimised the physical order these queries were routinely taking tens of seconds or hundreds of seconds and were a denial of service problem as well as just poor service. Now they aren't significant because they are so easy to do.

This sort of physical optimisation is all over the place, in watch lists, what links here lists, categories and such. Massive physical optimisation and PostgreSQL just can't do it practically.

For Wikipedia, the story is sad but simple: PostgreSQL isn't being used because its performance would suck.

This doesn't mean that the PostgreSQL design is bad - it has other advantages and exploits those advantages well. But efficient physical table optimisation of this sort isn't one of them.


On to the rest of your points, which mostly show you haven't been watching MySQL closely enough from 5.0 onwards and haven't ever seriously tried to optimise an application using it.

Quote:
Originally Posted by decibel
the default table type isn't ACID.
. Who cares? If you're designing an application to use MySQL you specify the engine you want and get what you need. InnoDB is built in, always available unless you deliberately change options to get rid of it and recompile yourself.

Quote:
Originally Posted by decibel
But worse that that, they *hide* that from you. For example, you can define refferential integrity on a MyISAM table without errer. The database just silently ignores it. And even when you try and create a much safer InnoDB table, if there's some reason the database can't do that instead of throwing an error it just silently creates a MyISAM one for you.
Welcome to SHOW TABLE STATUS and SHOW CREATE TABLE and INFORMATION_SCHEMA. It's hardly hidden - if your application cares, check it if you like. Application designers and DBAs are supposed to have a clue. It tends to be necessary to do the job...

Quote:
Originally Posted by decibel
Another fun one: MySQL thinks 'Feb 31' is a valid date. And that 5/0 is NULL and not an error. Yes, in 5.0 you can set strict mode to fix some of that stupidity, but then you have to make sure it's set, and I believe there's also restrictions on what table types you can use it with.
Old news. 5.0 is here already. No, there aren't restrictions on what engines you can use it with. Yes the old behavior is still available - backwards compatibility is a factor.

Quote:
Originally Posted by decibel
What it boils down to is that MySQL development is driven by marketing. They don't care one wit about implimenting a feature correctly, so long as they have something that allows them to say "yeah, we do that!", even if there's 3 dozen strings attached.
You prefer it if marketing people aren't asking the customers what they want? When it comes to implementation, it's led by two people who did literally write the book on the SQL standards and database compliance with them. You're seeing the results already. Expect MySQL to be the most standards-compliant one in the not so distant future.

Quote:
Originally Posted by decibel
Take their 'clustering' for example... it only works if *all your data fits in memory*. If everything fits in memory, what's the point of clustering?
Point me to the commodity server with 800GB of RAM which can keep on going after its power supply catches fire. MySQL Cluster has RAID 1 sets of servers so if you want you can configure it so a particular bit of data is still available after 1, 2 or more of the servers with a copy of it die. Disk backup is there. In 5.1, in beta, so is on-disk storage. Cluster is being used by telecoms providers for things like call authentication and record keeping with high real-time and reliability requirements.

Quote:
Originally Posted by decibel
Sadly, I bet that most folks who tout MySQL do so only because they don't have experience developing anything where data integrity is important, or where you need to be able to scale.
Of course, some of us have done accounting and payroll and such using Sybase, Oracle and Microsoft SQL Server and do know how to do things properly and just how capable MySQL is.

Quote:
Originally Posted by decibel
Livejournal is a more telling example... rather than switch to a more scaleable database when they ran into MySQL's limitations, they started piling on bandaid after bandaid. Based on yesterdays stats of about 300,000 posts, that's 3.5 TPS, which is not a very hard target to hit, even with the large amount of reads they're doing.
I suggest that you learn a bit more about LiveJournal. Posts are root posts, not total entries and definitely not all inserts and updates. Their database servers are write-limited because the vast majority of their reads are cached in Memcached.

Quote:
Originally Posted by decibel
in fact it is very difficult to scale it up
Been there, done that, it's not so hard when you're in the process of growing to be one of the top 20 sites according to Alexa.com.

How much will it cost me to get a 300 server BSD licensed replication setup with PostgreSQL? How about if I accept proprietary instead? What if I need 500 servers? I've worked with people using those numbers. The MySQL answer? No problem, it's included under the same GPL free license as the rest of the server and it's always there, compiled right in with the rest.

Quote:
Originally Posted by decibel
Now they're essentially stuck with quite a mess.
Seven database servers to be one of the top 20 sites in the world. How sad. Most people can only dream of scaling so far.

Quote:
Originally Posted by decibel
Same thing with the PostgreSQL community.
The one which announced two phase commit which isn't really what you need to be an XA distributed transaction client, while MySQL did the real thing and delivered XA client support? Both make implementation order choices.

Quote:
Originally Posted by decibel
BTW, I think it's rather telling that everyone who's promoted MySQL in this thread so far has said nothing more than "MySQL rocks!", which tells people absolutely nothing.
Are you any happier now?

Quote:
Originally Posted by decibel
I keep mentioning PostgreSQL only because I haven't really played with the other free databases.
I've done rather more than just play with MySQL. And it shows in the difference between our views of it.

Don't let this cause anyone to think that I think that PostgreSQL is anything other than a fine database. It is, in spite of my discussion of some of its limitations.

Last edited by James Day; 03-08-2006 at 06:56 PM.
 
Old 03-08-2006, 08:56 PM   #110
Crito
Senior Member
 
Registered: Nov 2003
Location: Knoxville, TN
Distribution: Kubuntu 9.04
Posts: 1,168

Rep: Reputation: 53
While I voted for PostgreSQL myself (and loathe MySQL) have to say Firebird finally got my attention this year. The more I read about it the more I like it.
 
Old 03-08-2006, 11:47 PM   #111
decibel
LQ Newbie
 
Registered: Nov 2003
Posts: 25

Rep: Reputation: 15
Quote:
Originally Posted by James Day
I'm the first DBA for Wikipedia
And perhaps the one whos salary is paid by MySQL? Or is it just a rumor that they're paying folks to work on wikipedia? Not that there's anything wrong with that, but it does make for a somewhat less than unbiased opinion. Granted, I currently work for a company doing PostgreSQL stuff, but I've had major beefs with MySQL since long before that.

Quote:
The problem is a fundamental design issue in PostgreSQL (and MyISAM in MySQL). It stores records in the physical order in which they were added
Not entirely true; it's not necessarily in the order you add the data either. It does happen to work out that way in either a new table or one with little or no pages in the free space map. But what you're refering to is known as an index organized table, and you're correct that PostgreSQL doesn't currently support that. (Though there is talk of that changing).

Quote:
Records were stored physically in the order in which they were added. People add in effectively random order (not right and that matters for working set issues, but it'll do for this discussion). Take the revision history of an article. Summary info for the last 50 revisions. Some articles have tens of thousands of revisions and people can freely move through them.

PostgreSQL case: 50 revisions means 50 random disk seeks to get the records.

InnoDB case: 1 or 2 and the second would probably be sequential.

It's worse though. Now go back 30,000 revisions. PostgreSQL 30,000 random seeks. InnoDB, maybe 50-100, mostly sequential.

Before we optimised the physical order these queries were routinely taking tens of seconds or hundreds of seconds and were a denial of service problem as well as just poor service. Now they aren't significant because they are so easy to do.

This sort of physical optimisation is all over the place, in watch lists, what links here lists, categories and such. Massive physical optimisation and PostgreSQL just can't do it practically.

For Wikipedia, the story is sad but simple: PostgreSQL isn't being used because its performance would suck.
Have you actually tried it? MySQL has it's own very substantial performance issues, or maybe more accurately it tends to force people to code things poorly due to missing features, especially in older versions. Just because a specific technique performs poorly in MySQL doesn't mean the same will be true in some other database.

In this case I don't see why this should be an issue. If someone wants revision xyz, you just find it in the index and then go read it in. Even if they are reading through the entire history of some article they round-trip time on the different page requests will dominate, so you'll never be able to have anything close to a sequential scan.

Quote:
Welcome to SHOW TABLE STATUS and SHOW CREATE TABLE and INFORMATION_SCHEMA. It's hardly hidden - if your application cares, check it if you like. Application designers and DBAs are supposed to have a clue. It tends to be necessary to do the job...
And based on that logic it's ok that data is silently truncated, because clearly the person entering the date in the first place should have known better. And clearly the person writing the application should have gotten their bounds checking correct.

Sorry, that's not how life works. People make mistakes. That includes coders and DBAs.

More importantly, why on earth should you expect a human to double-check that the machine did what you told it? When I hit the submit button on this form, I absolutely should not have to run diff between what I'm writing here and what shows up on the page. What I write here is exactly what should show up. Likewise, if I tell the database to create a foreign key, it should absolutely create it. Or tell me very explicitely that it can't. Same thing with creating a table of an invalid type. And trying to store 300 in a field that will only accept 127.

Quote:
Old news. 5.0 is here already. No, there aren't restrictions on what engines you can use it with. Yes the old behavior is still available - backwards compatibility is a factor.
Yes, backwards compatability is an issue, but they've created a situation where it is virtually impossible to trust the data in the database, because any session is free to change sql_mode at any time. Sure, your application code *shouldn't* be doing that improperly, but then again it also shouldn't be trying to insert invalid dates.

Quote:
You prefer it if marketing people aren't asking the customers what they want?
I'd prefer it if the marketing people wouldn't gloss over serious technical issues, misinforming countless unfortunate people who's first exposure to databases was MySQL. The mentality that it's perfectly fine to add the feature of multiple storage engines even though it makes it trivially easy to inadvertently lose acidity. Or that "storing something is better than storing nothing" is a "feature" that makes for a good database.

Quote:
Expect MySQL to be the most standards-compliant one in the not so distant future.
It's about time. But I'd be much happier if they would just admit their shortcommings instead of trying to fool people.

Quote:
Point me to the commodity server with 800GB of RAM which can keep on going after its power supply catches fire. MySQL Cluster has RAID 1 sets of servers so if you want you can configure it so a particular bit of data is still available after 1, 2 or more of the servers with a copy of it die. Disk backup is there. In 5.1, in beta, so is on-disk storage. Cluster is being used by telecoms providers for things like call authentication and record keeping with high real-time and reliability requirements.
Sure, there's some applications where keeping everything in memory might be the only possible way to meet the performance requirements, but those are few and far between. Yet many people go on about how "MySQL does clustering!", when the reality is that in most applications it's idea of clustering would be absurd overkill. What's one of those 800GB clusters cost anyway? Now compare that to a cluster where you don't have to fit the entire 800GB in memory, so instead you replicate across a few machines with 1TB of disk.

Of course, this isn't a fault of MySQL; it's the fault of it's cheerleaders that think that because they do have a (very expensive) form of clustering that means it's a great solution for scaling out. Would wikipedia be able to afford scaling it's database out using this technology? My guess is no (though then again, y'all have managed to round up 100 squid servers, so... )

Quote:
Of course, some of us have done accounting and payroll and such using Sybase, Oracle and Microsoft SQL Server and do know how to do things properly and just how capable MySQL is.
I've never had any issue with people who fully understand what they're getting into when choosing MySQL . There's certainly many areas where it's a great choice.

What I absolutely hate is that countless people have "chosen" MySQL with no understanding of what they're getting into. Those folks either eventually discover the limitations and then face a migration made painful by all the non-standard 'features' they've grown accustomed to (ie: why on earth is there a built-in if() function? CASE WHEN END is too much typing? Better yet, || as a logic operator instead of concatination like every other database and standard). Or, even worse, they drink from the Kool Aid and come away with a whole bunch of questionable knowledge about how a database should work (ie: everyone who argues that it's better that when you overflow a field you store some completely different value rather than throwing an error). This has done a tremendous dis-service to countless people.

Quote:
I suggest that you learn a bit more about LiveJournal. Posts are root posts, not total entries and definitely not all inserts and updates. Their database servers are write-limited because the vast majority of their reads are cached in Memcached.
Actually, I took that into account even though I didn't get into it. Assuming an average of 10 comments per post we're up to ~38 TPS (note T as in Transactions, I understand that there are more inserts and updates beyond that, but COMMIT is the gating factor). That's still not a very difficult target to hit. Granted, you're not going to do it on a run-of-the-mill server, but we're also not talking about anything close to 6 figures. I did that at a former employer (United Devices) back in 2001 on about $40k of RS6000 hardware with room to spare. And that was with a pretty high read rate as well (IIRC somewhere around 300 queries per second, probably about 2/3s read).

Quote:
How much will it cost me to get a 300 server BSD licensed replication setup with PostgreSQL?
$0. Both PostgreSQL and Slony are free. Hell, find me a more free license than BSD. Terms: 1) Must include license 2) May not sue UC-Berkley. The only thing I know of that beats it is no license (ie: public domain). And thanks to that freedom, you can also move up to commercial solutions should you so desire, and you have different companies to choose from. When it comes to MySQL, a quick google shows only one other company offering support, and I'm unaware of any other commercial versions of it.

Quote:
How about if I accept proprietary instead? What if I need 500 servers? I've worked with people using those numbers. The MySQL answer? No problem, it's included under the same GPL free license as the rest of the server and it's always there, compiled right in with the rest.
Only if you're not trying to sell your software. And I'm not really sure what you mean by proprietary there...

Quote:
The one which announced two phase commit which isn't really what you need to be an XA distributed transaction client, while MySQL did the real thing and delivered XA client support? Both make implementation order choices.
Sure, and the choice was to do 2PC and wait on doing XA because there's currently not really any demand for it (at least none that I've seen on any of the lists).


Quote:
I've done rather more than just play with MySQL. And it shows in the difference between our views of it.

Don't let this cause anyone to think that I think that PostgreSQL is anything other than a fine database. It is, in spite of my discussion of some of its limitations.
Limitations which (at least most) of the community is more than happy to admit to. I wouldn't have any issue with MySQL if they'd simply do the same, but they don't, either because it'd be bad marketing or because of ignorance. Granted, they have gotten better; back in the 3.x days they actually argued that table-level locks were the only logical choice, because it was "much faster than managing a lot of row locks". Uh, sure, if you only ever try and do one thing at a time in the database.

Take SQLite as an example: it's got plenty of limitations. For example, it only supports table level (well, to be technical, file level) locks. But they're very blunt about that limitation and what it means. The community will also readily point out when something someone's trying to do is going to run into those limitations.

In my experience this isn't the case with the MySQL community, though; they are far more likely to opine that MySQL is just the best thing there is, and that you couldn't possibly want more from a database. Just look at this thread as an example: how many posts are there that say nothing more than "MySQL ROCKS!"?

This extends beyond users as well. I've spent some time in the irc channel, trying to learn more about both the database and the community. At one point I was flat out accused of being a "PostgreSQL troll" while trying to understand something; and this was after I'd actually been in the channel for some time and had helped a bunch of their users with various questions. Granted, that was one twit, but it was a twit that I believe worked for MySQL AB.
 
Old 03-08-2006, 11:51 PM   #112
decibel
LQ Newbie
 
Registered: Nov 2003
Posts: 25

Rep: Reputation: 15
Quote:
Originally Posted by jcs32
(some people may prefer to evaluate 5/0 as NULL or insert Feb 31st as a valid date)
Ok, I'll bite. Why on earth could you possibly want to allow Feb 31st?? Or even 5/0 = NULL? If they added 'infinity' as a special value I could understand storing that, but 5/0 is absolutely not 'unknown'.
 
Old 03-08-2006, 11:53 PM   #113
decibel
LQ Newbie
 
Registered: Nov 2003
Posts: 25

Rep: Reputation: 15
Quote:
Originally Posted by MacNugget
Berhanie has it exactly right. It's disappointing that the technically superior PostgreSQL which enjoyed not only a major release (8.0) but also a significant point release (8.1)
Actually, in the PostgreSQL world, "point releases" are considered as major. There's very little reason why 8.0 is 8.0 and not just 7.5.
 
Old 03-08-2006, 11:55 PM   #114
decibel
LQ Newbie
 
Registered: Nov 2003
Posts: 25

Rep: Reputation: 15
Quote:
Originally Posted by Crito
While I voted for PostgreSQL myself (and loathe MySQL) have to say Firebird finally got my attention this year. The more I read about it the more I like it.
Ok, I'll bite; it what ways is it better than PostgreSQL? I'm seriously not trying to troll; I'm also curious and haven't had much luck finding info about it.
 
Old 03-09-2006, 04:45 AM   #115
jcs32
LQ Newbie
 
Registered: Aug 2005
Distribution: suse, gentoo
Posts: 10

Rep: Reputation: 0
Quote:
Originally Posted by decibel
Why on earth could you possibly want to allow Feb 31st??
Admittedly, I don't know an example.

Quote:
Originally Posted by decibel
Or even 5/0 = NULL?
Also no explicit example.

Quote:
Originally Posted by decibel
'infinity' as a special value
I guess adding more non-standard (and I guess 'inf' as a DB field value is non-standard?) would not terminally help the problem :-) NULL is used equivalently as 'not defined', which 5/0 actually is (korrekt?).

What both examples have in common is that they can occur, probably due to a wrong user input or a (hopefully small) program error upstream, but also due to some noise in the data (especially 5/0).
See, I'm mainly using databases to structure my own data and I'm usually little concerned about web-applications or other people inserting trash. Often, descriptive text fields are only auxiliary and not essential. 5/0 could easily happen (although it should be caught earlier in the first place), and inserting NULL may be bad logic, but the outcome is similar in effect. I can simply ignore all NULL fields (and actually validly so, as long as I know which and how many are NULL), as they are undefined and accept those field cannot be further analyzed, instead of adding more code to deal with the SQL error.

Of course, this is only acceptable for some specialized niche applications (e.g. structuring noisy raw data for downstream analysis while retaining all the nice features a DB has including the ability to go back or share the datasource). Personally, I'm also not convinced it is wise to have that as a default behavior, regardless of backward compatibility. I regard it as a left-over from the early blog only applications of MySQL. On the other hand, people would likely never switch on 'sloppy mode' for fear undefined perils might await their data. :-)
Now it awaits all of us . (Ha Ha)

In other words, I can see positive effects for my work, but I wouldn't want that feature in an accounting application where such things ought not possibly be correct. Fortunately, it can be switched off.
 
Old 03-09-2006, 06:58 AM   #116
fikret
LQ Newbie
 
Registered: Jan 2005
Posts: 28

Rep: Reputation: 15
Quote:
Originally Posted by decibel
Ok, I'll bite; it what ways is it better than PostgreSQL? I'm seriously not trying to troll; I'm also curious and haven't had much luck finding info about it.
You couldn't find info about Firebird???!!! You are kidding, right? Or you couldn't find info about Firebird vs PostgreSQL?

Read this for a start:

http://www.firebirdnews.org/docs/fb2min.html

Also, check http://www.fyracle.org and http://www.ibphoenix.com.
And don't forget official site http://www.firebirdsql.org
 
Old 03-09-2006, 10:14 AM   #117
decibel
LQ Newbie
 
Registered: Nov 2003
Posts: 25

Rep: Reputation: 15
Quote:
Originally Posted by jcs32
NULL is used equivalently as 'not defined', which 5/0 actually is (korrekt?).
BZZT. If you get far enough along in math you'll find that 5/0 actually is defined; it's infinity, which is a perfectly valid mathematical concept, even if you can't really duplicate it in reality.

FWIW, PostgreSQL allows infinity as a value in floating-point, and I'd bet it's because the standard says so.

Quote:
See, I'm mainly using databases to structure my own data and I'm usually little concerned about web-applications or other people inserting trash. Often, descriptive text fields are only auxiliary and not essential. 5/0 could easily happen (although it should be caught earlier in the first place), and inserting NULL may be bad logic, but the outcome is similar in effect. I can simply ignore all NULL fields (and actually validly so, as long as I know which and how many are NULL), as they are undefined and accept those field cannot be further analyzed, instead of adding more code to deal with the SQL error.

Of course, this is only acceptable for some specialized niche applications (e.g. structuring noisy raw data for downstream analysis while retaining all the nice features a DB has including the ability to go back or share the datasource). Personally, I'm also not convinced it is wise to have that as a default behavior, regardless of backward compatibility. I regard it as a left-over from the early blog only applications of MySQL. On the other hand, people would likely never switch on 'sloppy mode' for fear undefined perils might await their data. :-)
Now it awaits all of us . (Ha Ha)

In other words, I can see positive effects for my work, but I wouldn't want that feature in an accounting application where such things ought not possibly be correct. Fortunately, it can be switched off.
Unfortunately, stuff like this can also be switched back on, which means now your data is 100% useless.

How's that work? To make typing easy, take an example that works with tinyints. Max value is 127. Kinda odd number, since a signed tinyint in C maxes out at 128. So your application coder dutifully ensures that you can't overflow by doing

Code:
assert( variable <= 128 );
Fortunately, someone comes along and finds this bug and fixes it. Unfortunately, the software was already in production. Wondering the extent of the damage, you run a query against the database and discover that 58 rows contain the value 127.

Those rows are now invalid data points.

Even in your case, where you can tolerate some amount of error, you need to throw all that data out, because you have absolutely no way to know what value was actually stuck in there. Except in a trivial piece of code you have no way to be certain that no other operation could have possibly touched that field, so you don't even know if that data was limited to either 127 or 128. Which probably means you need to throw a lot more data out since you now have big holes in your data.

So, now you have a 'database' thats written by people who thought this was just fine for 10 years. You really want to trust your data to that kind of quality?

BTW, I don't do C code myself, but I have heard from others that the MySQL source is pretty much a quagmire. Lord knows what other serious problems are sitting in the swamp.
 
Old 03-09-2006, 12:22 PM   #118
Crito
Senior Member
 
Registered: Nov 2003
Location: Knoxville, TN
Distribution: Kubuntu 9.04
Posts: 1,168

Rep: Reputation: 53
Quote:
Originally Posted by decibel
Ok, I'll bite; it what ways is it better than PostgreSQL? I'm seriously not trying to troll; I'm also curious and haven't had much luck finding info about it.
Don't believe I said it was better than PostgreSQL. In any case, the Phoenix PHP application server is one major difference:
http://www.janus-software.com/phpserver.html

Together they provide a complete end-to-end (development to deployment) solution that competes well against offerings from the big dawgs like Oracle and Microsoft.

EDIT: And for an old VB/Access developer like myself, Phoenix Object Basic looks like what should have happened after VB 6.0 instead of the dot-net/mono crap we got instead.
http://www.janus-software.com/phoenix_screenshots.html

Last edited by Crito; 03-09-2006 at 12:52 PM.
 
Old 03-09-2006, 05:50 PM   #119
jcs32
LQ Newbie
 
Registered: Aug 2005
Distribution: suse, gentoo
Posts: 10

Rep: Reputation: 0
Smile

Quote:
Originally Posted by decibel
BZZT. If you get far enough along in math you'll find that 5/0 actually is defined; it's infinity, which is a perfectly valid mathematical concept, even if you can't really duplicate it in reality.

FWIW, PostgreSQL allows infinity as a value in floating-point, and I'd bet it's because the standard says so.
Although slightly off-topic I would say we are both right, depending on the interpretation.

http://en.wikipedia.org/wiki/Division_by_zero

there especially "Under the standard rules for arithmetic on integers, rational numbers, real numbers and complex numbers, division by zero is undefined. Division by zero must be left undefined in any mathematical system that obeys the axioms of a field."

However, as you said, under certain circumstances it seems to make sense to define division by zero as 'inf', in my opinion that should not include 5/0, as it is an arithmetic expression.

But "The IEEE floating-point standard, supported by almost all modern processors, specifies that every floating point arithmetic operation, including division by zero, has a well-defined when a is negative, and NaN (not a number) when a = 0."

So what you could say is that the MySQL interpretation of 5/0 is probably not IEEE conform and Postgres make interesting mathematical assumptions. Hm.
 
Old 03-09-2006, 05:53 PM   #120
jcs32
LQ Newbie
 
Registered: Aug 2005
Distribution: suse, gentoo
Posts: 10

Rep: Reputation: 0
sorry, correction

Sorry, I messed up the second quote:
"The IEEE floating-point standard, supported by almost all modern processors, specifies that every floating point arithmetic operation, including division by zero, has a well-defined result. In IEEE 754 arithmetic, a/0 is positive infinity when a is positive, negative infinity when a is negative, and NaN (not a number) when a = 0."
 
  


Reply

Tags
members choice awards


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Snort database: Closing connection to database "" Homer Glemkin Linux - Security 2 07-14-2005 06:58 PM


All times are GMT -5. The time now is 11:16 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration