Well, HSQLDB is embedded, but only inside a java application
True, but that's why I said I'd need to know more about his application.
It persists data in a flat file that it loads on start.
Not quite. HSQLDB uses an SQL script of the transactions to recreate the database. However, this script is significantly reduced in size if you use CACHED tables.
If you've got more than 1000 records
Again, depends on the data and the application. 1000 records is usually not a whole lot to cache in memory. And with CACHED table types, you could easily go up to millions of records without stressing the user's machine.
you might want to go with something more robust, like MS Access.
That's what he was trying to get away from.
Berkeley DB isn't a "database" in the sense most people think.
It's not an "SQL" database, but it is a database. (Technically, even a filesystem is a type of database, but we won't go there.) Again, it depends on his application. He gave no requirement that the database support SQL, so I went with the most natural assumption: It doesn't need it.
It's not relational, and there's no SQL (there may be a SQL driver, but it'd be totally inefficient.
However, my point is that it's not standing still. It's certainly improving, so we can't just keep pointing out its past mistakes.
A fair enough point. When MySQL "arrives" I will be the happiest person on the block. Unfortunately, I am very worried that MySQL won't so much as fix the issues as cover them over with incomplete, incorrect, or incompatible features as they have in the past.:-(
Truth is, most people want ACID (and transaction processing) because it saves them from having to think too much.
I seriously hope you don't approach real database work this way. ACID is NOT about "not thinking too much". It's about making it impossible for unexpected bugs to corrupt data, or leaving a transaction halfway completed.
How would you feel if your bank:
- Deducted the money for an savings to checking transfer, but failed to add the money to the checking account? - Accidently associated your account with someone else, thus denying you access to your money? - Failed to reschedule an auto-pay, making you delinquent on your car/credit/house payments?
InnoDB is free, it comes with the basic MySQL distribution and is GPLv2'd.
Seems you're right. I misread the InnoDB page.
You can change compatibilit settings, so you're mistaken on the ` vs. " problem.
How does that help tools vendors or anyone attempting to write in support for MySQL? Most users can't or won't run it in ANSI compliant mode because they already have non-compliant code running on the same server.
4.1 is in "gamma". Good enough if you ask me.
NOT good enough for business. Unless it's marked stable, it doesn't go into a production environment.
Autoincrement is non-standard SQL anyway, so what do you expect?
I expected sensible handling of nulls vs. zeros. Again, no other database thinks this way, so MySQL is simply making things more complicated for tools and software vendors.
Based only on your list, I would have looked at an embedded database like HSQL or Berkeley DB. These would have been less intensive on your target machines, faster performing, more secure (no network connection), and easier to install. Unfortunately, I can't give a realistic recommendation without knowing more about the application.
Your specs could even be met with databases like PostgreSQL, Firebird, Xindice, and quite a few others.
No, that's pretty much it. But MySQL supporters often criticize Postgres for Vacuums, so that's why I made my comment about *gasp* maintenance. After all, that cron job just kills them.:-)
Of course, some of us never need to vacuum because we never delete any data.:-)
MySQL has a modular design, allowing you to use any of several database backends, each with different design priorities. If data integrity is a priority for you, RTFM and pick the right backend.
As I understand it, InnoDB (which I assume is what you're referring to) costs money to acquire and as such is NOT part of the standard database engine. It's really just another database engine using MySQL as a facade.
This is true of pretty much all DBMS's. MySQL's development cycle is quite delightfully quick, meaning that if people want certain features added, it doesn't take long to get them added.
MySQL is the ONLY database that won't execute:
select * from "My Table"
Instead, you have to execute:
select * from `My Table`
Do you have ANY idea how much that screws up those of us in the database tools business?
No extensibility in the engine (functions, stored procedures, etc.)
Ummm... MySQL has those.
In 5.0 Alpha. i.e. Not here yet.
No subselects
Yes it does, as of version 4.1. It's not their fault if you're more than a full release behind
Again, 4.1 is a non-production release. The latest stable is 4.0.
The special handling of null forces you to write slightly less braindead code.
So you're saying that inserting zeros instead of nulls (or no value at all) for auto-increment columns leads to less brain-dead code? All it does for me is make my database tools that much more complicated to code.
For a moment there, I thought you meant that Yahoo was processing company financial data with MySQL. Then I realized that they use it just for displaying market data and the like.
But what are these alternatives you mention that are so much better suited for every possible scenario?
There is, of course, no tool that meets the needs of every possible scenario. Instead, there are tools that meet the needs of common scenarios. Most of what MySQL is being (improperly) used for could be easily replaced with PostgreSQL. Postgres offer similar performance, but takes a minor hit for data integrity. As a bonus, you gain sub-selects, stored procedures, SQL-92 compliance, and other features of a "real" SQL database.
MySQL is quite decent for something like a blog, but why even bother with a complete server in those cases? An embedded database such as Berkeley DB or HSQL (formerly Hypersonic) would provide better performance and would get rid of security issues inherent in running a complete database server.
In still other instances, SQL databases are misused for large object data storage. In many of these instances, an Object Database such as ObjectStore (or your favorite open source choice of the 1000+ options) will provide better performance, without sacrificing much in the way of database management. (Standard database management tools are usually insufficient for dealing with databases containing large amounts of LOBs.)
Basically, the choice in database and database technology should be carefully weighed against the application instead of saying "I know SQL and MySQL is 1337!"
Touchy, aren't we? I think that most of us here understand core database concepts (including ACID) just fine. (At least, I hope most of us do.) The problem is that it has become all to common to use MySQL in situations were data-loss and data-integrity can be measured in real dollars. MySQL is completely the wrong tool for the job, and as such has been heavily criticized.
In fact, it is very difficult to understand where MySQL fits in today's technological environment. On one hand you have truly powerful database servers that guarantee data safety. On the other hand you have simple embedded databases that run much faster than MySQL. Where does this leave MySQL? With nothing more than a lot of "it's Open Source!" momentum.
Okay, as an industry professional, I tire of books calling themselves "for professionals". Don't most professionals already know about index types and choosing their usage?
More importantly, what self-respecting professional would be caught dead using MySQL?
No data integrity Completely non-standard SQL No extensibility in the engine (functions, stored procedures, etc.) No subselects Weird handling of '0' vs. null etc.
Back when MySQL was created, it was a great option for when you needed a simple database to store non-critical data. But then everyone decided that MySQL was super-1337 and that all other databases were simply part of "the evil empire".
As a result, REAL alternatives like PostgreSQL were just ignored when they came on the scene. After all, you have to perform *gasp* maintenance on Postgres! *sigh*
That's why NATs are combined with firewalls. You can punch holes in the device as necessary. In all other situations, the NAT device is firewalling the connection for a reason.
Keep in mind that you can always load a machine into the DMZ. In that instance, incoming connections are *always* forwarded to the desired machine. Truth be told, though, I've only ever used this functionality once. And looking back it probably would have made more sense to forward the individual port.
except that the article is about describing SPECIAL RELATIVITY which is a great deal harder to comprehend, let alone explain in a 5 minute presentation. Your discussion, while being quite exceptional is on GENERAL RELATIVITY.
Actually, this seemed wrong so I looked it up. The grandparent described SPECIAL relativity (time warps and all that) but called it GENERAL relativity. His entry would be acceptable. My attempt (look right above this post) described GENERAL relativity.
Everyone always gets confused because Einstein published Special Relativity before he published General when it seems like it should be the other way around.
How about this: There are two ways to accelerate an object. You can either push on it, or pull on it. Either way, it accelerates due to the energy imparted on it. In the case of a rocket, energy is "pushing" the object forward. In the case of gravity, a force traveling at the speed of light is "pulling" you into accelerating.
The issue is, if we examine the object from a local frame of reference, we can find no difference between pulling and pushing. If we pull on the object, we may observe the object being "streched" from the front until inertia is overcome. If we push from the back, we observe "compression" from the rear to the front. Yet in both instances, the amount of "stretching" vs. "compression" is the same. i.e. The particles behave exactly the same in transmitting the force. From this we can derive that there is no actual difference in pulling vs. pushing, and that we are in fact simply warping the craft due to inertia.
Since we know from General Relativity that things going faster experience greater time and space compression than objects going slower, we can derive that our object is experiencing different levels of time and space distortion from one end to the other. We can call this effect "inertia" and can unequivocally state that it caused by "acceleration". Since the effect is the same whether you're pushing or pulling, it is thus safe to say that there is no difference between gravity and acceleration. i.e. Gravity is acceleration.
Hmm... I suppose that's sort of it. Not sure if (or how many) errors I made. Anyone?
Personally, I found NAT to be a fairly elegant solution. Definitely not perfect, but completely in line with network structuring. In comparison, proxies (even SOCKS) were the devil's spawn.
But it dosen't solve the problem.
It solved the problem at hand, which was to stop handing out valuable IPs to machines that didn't need it. As a new problem arises (large numbers of devices that DO need public IPs), those using the network will come up with proper solutions (e.g. IPv6)
Is this like the predication that we'd run out of IP addresses in the late 1990's. We all know that happened. Wait, no it didn't. Humans fixed the problem with private networks and NATing. In the process, they improved security and sanctity of their networks.
It's a funny thing, networks. You see, since humans control them, they make changes and adjustments in response to the needs of the network. Thus the network grows, adapts, and becomes a more powerful entity.
That being said, there are two things I wish I could exorcise from the net: Spam and viruses. These two creatures are responsible for more useless traffic than just about anything else. It would also be nice if protocols like GNUTella died or were fixed. The number of useless packets generated by such protocols is amazing.
Wrong!! Citrix Metaframe does not run on RDP. Citrix still uses their superfast and lean ICA protocol.
I didn't say it doesn't. My point was that ICA plugs into Microsoft's RDP server. Thus you have to license Terminal Server, Terminal Server Licenses, and Citrix Licenses. But ICA still kicks serious ass.:-)
Microsoft's RDP client is called Remote Desktop Client, and has nothing to do with Citrix's protocol or products. Microsoft shafted Citrix with their cheap knock-off that doesn't work 1/10 as well as Citrix's ICA protocol.
Citrix currently runs on top of Microsoft's RDP functionality. That's why you need Terminal Server, Terminal Server Client Licenses, AND Citrix licenses. You used to be able to get it all from Citrix. (At a much lower cost I might add.)
Microsoft pretty much pushed Citrix out of the market and did their best to relegate Remote Desktop Networking to "Admin" functionality. Assholes.
Grab the latest copy of Azureus. I've had no issues between it and UltraVNC. Of course, it only does torrents, but what do you need those other P2P protocols for anyway?;-)
It's not fast if you're planning on trying to connect to anything that's not Windows... Like I suspect a huge number of us are.
Eh? UltraVNC is a fork of TightVNC, so it supports the "tight" protocols just fine. As long as your Unix box is using X-Windows -> VNC translation, the performance should be just as good as UltraVNC on Windows. Before UltraVNC came along, Unix was the best place to use VNC, because the X protocol could be directly interpreted without the need for a special video driver.
Slashdot Mirror
Close, but not quite.
:-)
Well, HSQLDB is embedded, but only inside a java application
True, but that's why I said I'd need to know more about his application.
It persists data in a flat file that it loads on start.
Not quite. HSQLDB uses an SQL script of the transactions to recreate the database. However, this script is significantly reduced in size if you use CACHED tables.
If you've got more than 1000 records
Again, depends on the data and the application. 1000 records is usually not a whole lot to cache in memory. And with CACHED table types, you could easily go up to millions of records without stressing the user's machine.
you might want to go with something more robust, like MS Access.
That's what he was trying to get away from.
Berkeley DB isn't a "database" in the sense most people think.
It's not an "SQL" database, but it is a database. (Technically, even a filesystem is a type of database, but we won't go there.) Again, it depends on his application. He gave no requirement that the database support SQL, so I went with the most natural assumption: It doesn't need it.
It's not relational, and there's no SQL (there may be a SQL driver, but it'd be totally inefficient.
That's an amusing statement, because MySQL does exactly that.
However, my point is that it's not standing still. It's certainly improving, so we can't just keep pointing out its past mistakes.
:-(
A fair enough point. When MySQL "arrives" I will be the happiest person on the block. Unfortunately, I am very worried that MySQL won't so much as fix the issues as cover them over with incomplete, incorrect, or incompatible features as they have in the past.
Truth is, most people want ACID (and transaction processing) because it saves them from having to think too much.
I seriously hope you don't approach real database work this way. ACID is NOT about "not thinking too much". It's about making it impossible for unexpected bugs to corrupt data, or leaving a transaction halfway completed.
How would you feel if your bank:
- Deducted the money for an savings to checking transfer, but failed to add the money to the checking account?
- Accidently associated your account with someone else, thus denying you access to your money?
- Failed to reschedule an auto-pay, making you delinquent on your car/credit/house payments?
ACID is about data integrity, pure and simple.
InnoDB is free, it comes with the basic MySQL distribution and is GPLv2'd.
Seems you're right. I misread the InnoDB page.
You can change compatibilit settings, so you're mistaken on the ` vs. " problem.
How does that help tools vendors or anyone attempting to write in support for MySQL? Most users can't or won't run it in ANSI compliant mode because they already have non-compliant code running on the same server.
4.1 is in "gamma". Good enough if you ask me.
NOT good enough for business. Unless it's marked stable, it doesn't go into a production environment.
Autoincrement is non-standard SQL anyway, so what do you expect?
I expected sensible handling of nulls vs. zeros. Again, no other database thinks this way, so MySQL is simply making things more complicated for tools and software vendors.
Based only on your list, I would have looked at an embedded database like HSQL or Berkeley DB. These would have been less intensive on your target machines, faster performing, more secure (no network connection), and easier to install. Unfortunately, I can't give a realistic recommendation without knowing more about the application.
Your specs could even be met with databases like PostgreSQL, Firebird, Xindice, and quite a few others.
No, that's pretty much it. But MySQL supporters often criticize Postgres for Vacuums, so that's why I made my comment about *gasp* maintenance. After all, that cron job just kills them. :-)
:-)
Of course, some of us never need to vacuum because we never delete any data.
As I understand it, InnoDB (which I assume is what you're referring to) costs money to acquire and as such is NOT part of the standard database engine. It's really just another database engine using MySQL as a facade.
This is true of pretty much all DBMS's. MySQL's development cycle is quite delightfully quick, meaning that if people want certain features added, it doesn't take long to get them added.
MySQL is the ONLY database that won't execute: Instead, you have to execute: Do you have ANY idea how much that screws up those of us in the database tools business?
No extensibility in the engine (functions, stored procedures, etc.)
Ummm... MySQL has those.
In 5.0 Alpha. i.e. Not here yet.
No subselects
Yes it does, as of version 4.1. It's not their fault if you're more than a full release behind
Again, 4.1 is a non-production release. The latest stable is 4.0.
The special handling of null forces you to write slightly less braindead code.
So you're saying that inserting zeros instead of nulls (or no value at all) for auto-increment columns leads to less brain-dead code? All it does for me is make my database tools that much more complicated to code.
For a moment there, I thought you meant that Yahoo was processing company financial data with MySQL. Then I realized that they use it just for displaying market data and the like.
Give me a heart attack, why don't you?!
But what are these alternatives you mention that are so much better suited for every possible scenario?
There is, of course, no tool that meets the needs of every possible scenario. Instead, there are tools that meet the needs of common scenarios. Most of what MySQL is being (improperly) used for could be easily replaced with PostgreSQL. Postgres offer similar performance, but takes a minor hit for data integrity. As a bonus, you gain sub-selects, stored procedures, SQL-92 compliance, and other features of a "real" SQL database.
MySQL is quite decent for something like a blog, but why even bother with a complete server in those cases? An embedded database such as Berkeley DB or HSQL (formerly Hypersonic) would provide better performance and would get rid of security issues inherent in running a complete database server.
In still other instances, SQL databases are misused for large object data storage. In many of these instances, an Object Database such as ObjectStore (or your favorite open source choice of the 1000+ options) will provide better performance, without sacrificing much in the way of database management. (Standard database management tools are usually insufficient for dealing with databases containing large amounts of LOBs.)
Basically, the choice in database and database technology should be carefully weighed against the application instead of saying "I know SQL and MySQL is 1337!"
Some other database options include:
DaffodilDB
SAP DB
FireBird DB
Cloudscape (Soon to be open source)
Xindice (XML Database)
ObjectDB
DB4O
Prevayler
Touchy, aren't we? I think that most of us here understand core database concepts (including ACID) just fine. (At least, I hope most of us do.) The problem is that it has become all to common to use MySQL in situations were data-loss and data-integrity can be measured in real dollars. MySQL is completely the wrong tool for the job, and as such has been heavily criticized.
In fact, it is very difficult to understand where MySQL fits in today's technological environment. On one hand you have truly powerful database servers that guarantee data safety. On the other hand you have simple embedded databases that run much faster than MySQL. Where does this leave MySQL? With nothing more than a lot of "it's Open Source!" momentum.
High Performance and Incredible Data Integrity?
I never said that. Please don't act like I did.
Okay, as an industry professional, I tire of books calling themselves "for professionals". Don't most professionals already know about index types and choosing their usage?
More importantly, what self-respecting professional would be caught dead using MySQL?
No data integrity
Completely non-standard SQL
No extensibility in the engine (functions, stored procedures, etc.)
No subselects
Weird handling of '0' vs. null
etc.
Back when MySQL was created, it was a great option for when you needed a simple database to store non-critical data. But then everyone decided that MySQL was super-1337 and that all other databases were simply part of "the evil empire".
As a result, REAL alternatives like PostgreSQL were just ignored when they came on the scene. After all, you have to perform *gasp* maintenance on Postgres! *sigh*
You can keep "High Performance MySQL". I'm holding out for "Incredible Data Integrity Management with MySQL". :-D
That's why NATs are combined with firewalls. You can punch holes in the device as necessary. In all other situations, the NAT device is firewalling the connection for a reason.
Keep in mind that you can always load a machine into the DMZ. In that instance, incoming connections are *always* forwarded to the desired machine. Truth be told, though, I've only ever used this functionality once. And looking back it probably would have made more sense to forward the individual port.
except that the article is about describing SPECIAL RELATIVITY which is a great deal harder to comprehend, let alone explain in a 5 minute presentation. Your discussion, while being quite exceptional is on GENERAL RELATIVITY.
Actually, this seemed wrong so I looked it up. The grandparent described SPECIAL relativity (time warps and all that) but called it GENERAL relativity. His entry would be acceptable. My attempt (look right above this post) described GENERAL relativity.
Everyone always gets confused because Einstein published Special Relativity before he published General when it seems like it should be the other way around.
How about this: There are two ways to accelerate an object. You can either push on it, or pull on it. Either way, it accelerates due to the energy imparted on it. In the case of a rocket, energy is "pushing" the object forward. In the case of gravity, a force traveling at the speed of light is "pulling" you into accelerating.
The issue is, if we examine the object from a local frame of reference, we can find no difference between pulling and pushing. If we pull on the object, we may observe the object being "streched" from the front until inertia is overcome. If we push from the back, we observe "compression" from the rear to the front. Yet in both instances, the amount of "stretching" vs. "compression" is the same. i.e. The particles behave exactly the same in transmitting the force. From this we can derive that there is no actual difference in pulling vs. pushing, and that we are in fact simply warping the craft due to inertia.
Since we know from General Relativity that things going faster experience greater time and space compression than objects going slower, we can derive that our object is experiencing different levels of time and space distortion from one end to the other. We can call this effect "inertia" and can unequivocally state that it caused by "acceleration". Since the effect is the same whether you're pushing or pulling, it is thus safe to say that there is no difference between gravity and acceleration. i.e. Gravity is acceleration.
Hmm... I suppose that's sort of it. Not sure if (or how many) errors I made. Anyone?
NAT is nothing more than a hack.
Personally, I found NAT to be a fairly elegant solution. Definitely not perfect, but completely in line with network structuring. In comparison, proxies (even SOCKS) were the devil's spawn.
But it dosen't solve the problem.
It solved the problem at hand, which was to stop handing out valuable IPs to machines that didn't need it. As a new problem arises (large numbers of devices that DO need public IPs), those using the network will come up with proper solutions (e.g. IPv6)
Spammers, virus copiers and script kiddies will simply be hunted down for sport and tortured on live TV.
Right up until Ah-nold shows up and ruins everything by surviving!
Is this like the predication that we'd run out of IP addresses in the late 1990's. We all know that happened. Wait, no it didn't. Humans fixed the problem with private networks and NATing. In the process, they improved security and sanctity of their networks.
It's a funny thing, networks. You see, since humans control them, they make changes and adjustments in response to the needs of the network. Thus the network grows, adapts, and becomes a more powerful entity.
That being said, there are two things I wish I could exorcise from the net: Spam and viruses. These two creatures are responsible for more useless traffic than just about anything else. It would also be nice if protocols like GNUTella died or were fixed. The number of useless packets generated by such protocols is amazing.
Yes, thank you for the recap.
:-)
Wrong!! Citrix Metaframe does not run on RDP. Citrix still uses their superfast and lean ICA protocol.
I didn't say it doesn't. My point was that ICA plugs into Microsoft's RDP server. Thus you have to license Terminal Server, Terminal Server Licenses, and Citrix Licenses. But ICA still kicks serious ass.
Oh for crying out loud.
RDP = Remote Desktop Protocl
ICA = Independent Computing Architecture
VNC = Virtual Network Computing
Microsoft's RDP client is called Remote Desktop Client, and has nothing to do with Citrix's protocol or products. Microsoft shafted Citrix with their cheap knock-off that doesn't work 1/10 as well as Citrix's ICA protocol.
Microsoft. Has a VNC client. That's news to me!
Are you referring to Microsoft's RDP Client by any chance?
Citrix currently runs on top of Microsoft's RDP functionality. That's why you need Terminal Server, Terminal Server Client Licenses, AND Citrix licenses. You used to be able to get it all from Citrix. (At a much lower cost I might add.)
Microsoft pretty much pushed Citrix out of the market and did their best to relegate Remote Desktop Networking to "Admin" functionality. Assholes.
Grab the latest copy of Azureus. I've had no issues between it and UltraVNC. Of course, it only does torrents, but what do you need those other P2P protocols for anyway? ;-)
It's not fast if you're planning on trying to connect to anything that's not Windows... Like I suspect a huge number of us are.
Eh? UltraVNC is a fork of TightVNC, so it supports the "tight" protocols just fine. As long as your Unix box is using X-Windows -> VNC translation, the performance should be just as good as UltraVNC on Windows. Before UltraVNC came along, Unix was the best place to use VNC, because the X protocol could be directly interpreted without the need for a special video driver.