It's sad how all criticisms of MySQL on slashdot are consistently modded down. Although MySQL is a fine product with a lot going for it - there is plenty to be *legitimately* critical about.
Is it that the MySQL supporters on slashdot are only familar with application programming interfaces to relational databases - and so don't understand the differences between a modern relational database and MySQL? Or are they simply pushing the product that they are most familiar with?
I've been involved in purchases of millions of dollars in relational database software over the last sixteen years; been a DBA on Oracle, Informix, and DB2; and developed on those as well as Sybase, SQL Server, Adabas (SAP-DB), Dbase IV, and Access. And I can say that there are plenty of traditional IT applications that I would try Postgresql out on - just about everything in the OLTP arena that doesn't require massive scalability. And unfortunately, there are far fewer traditional IT database applications that I would recommend MySQL for - it simply lacks too many features that are already available in postgresql, and that in the RealWorld(tm) save your bacon.
In addition to looking for spam you could use this approach to initially filter your valid email into various topical inboxes.
So, with some modifications it could move all the mail you get from work, from various hobby/educational/professional listserves and put them into separate folders for you to scan.
I'd find this tremendously useful, and it would probably even enable me to subscribe to a few more listserves - without the worry of being buried in the resulting email.
So, security benefits from a strategy in which it fails gracefully, and is best implemented in small, easily manageable pieces?
And security also benefits from a reliance upon complex (human) intelligence instead of simplistic boolean concepts of success/fail?
Hmmm, doesn't that sound like just about every other kind of system in the world? Whether we're talking about how to build elegant systems that fail gracefully, or how to build systems that deliver what you want rather than what is easy, there are examples all around us.
However, if we look farther ahead and we will see another set of problems. For example, a reliance upon humans to evaluate system performance (whether the system is a security system or a telephone network) is expensive and is also unreliable. One of the next steps is SPC - where we can provide tools to help the humans automate much of the drudgery of looking through gazillions of bytes of low-level information.
MCI always paid as late as possible, and I heard that Worldcom often simply didn't pay many of its creditors.
The funny part about this is that last year they were looking for ways to save money - and decided to go with cheaper coffee in one of their largest facilities.
So, Worldcom failed to integrate the sixty companies that they acquired - and their operations were bleeding money like an arterial wound. Additionally, they had overspent on MCI by about $10 billion, and had $7 billion + hidden in accounting gimmicks --- but thank god they saved $400 a year on cheap coffee.
just another 'decision made at internet speed' I suppose.
The problem with putting 100% of the business logic in the middle tier dogma is that most folks saying this haven't sufficiently tested it.
Aside from the valid and well-known disadvantages to implementation within the database, the following advantages are unfortunately not well known to having a logical application layer constructed from stored procedures & views:
#1: database technology typically outlasts application technology. So - business logic implemented in T/SQL or PL/SQL in 1994 still runs perfectly fine today. If it had been implemented in pro/c it would have them probably been re-implemented in VB, then C/CGI, then perhaps Perl, then Java, and now.NET.
#2: physical tuning. Databases physical schemas often have to be changed to deal with changing performance needs. If the interface from the application layer to the database is through a stored procedure the entire change can be implemented by a DBA. On the other hand, if the application is using selects/deletes/updates on the database a physical schema change will generally require a combined effort of programmers and DBAs - and suddenly become a significant project.
#3 Adaptability. Similar to the above issue, logic within the database allows the DBA to re-engineer the physical schema to one with greater flexibility without impacting the interface to existing applications. The alternative typically involves duct-tape-and-bailing wire to ensure minimal impact to existing application code.
#4 Capability. Some database modeling patterns involve the use of tree and network patterns that allow tons of flexibility but poor performance for scanning queries. The poor performance can be addressed with triggers that also insert to read-only tables. This capability provides extrordinarily flexible, adaptable, and reusable schemas, with no performance disadvantages. But - it is practically impossible if you are doing selects/deletes/inserts from the application layer.
So, yeah 'common knowledge' says that you need to use just a subset of database functionality, and move everything into a middle application layer. Then again 'common knowledge' in 1994 said that client-server was the future of database architectures. And quite a few projects suffered because of the parrots that endlessly repeated the dogma/mantra that client-server was best. Business logic in the middle-tier is the exact same thing.
I continually hear mysql folks repeat the dogma that it is faster than the commercial alternatives - but I've *never* seen a benchmark that backed this up - and wasn't trivial. Can anyone point to something beyond the home hobbiest level?
Since these days OLAP & warehousing are *core* functionality, any database that cannot provide at least nominal capabilities in this area isn't a serious contender beyond the web boutique/minor league applications.
Although some analytical functionality is needed today within most OLTP applications (summary tables, search tables, simplistic report tables, etc), a pure OLAP/Warehousing benchmark would be the easiet to compare to commercial alternatives.
So, how about something along the lines of TPCDs - representing, say, a 300 gbyte reporting application with dimensional tables.
Oracle, DB2, Informix, and Sybase easily delver solutions for this with support for partitioning, unions, parallelism, bitmap indexes, etc. SQL Server can as well, just to a lesser extent.
But, have any benchmarks - or success stories established that mysql is even a player in this space? Or is this just another popular delusion?
Nobody wears gloves to prevent their fingerprints from being recorded without their permission.
Then again - there's no way to perform that cheaply and easily.
But Mega-Corp, with its 100,000 employees could probably very easily have another company score its employees on likelihood of having smoked, used drugs, etc - all based on changes to retina images.
Why should you care if you're innocent? Hmmm, where have we heard that before.
I use both join forms with SQL Server, and have finally gotten used to the explicit form. However, the Microsoft implementation is less than perfect: - you can't use derrived tables - you can't group one table and then join it to another - there are also limitations in how you can use outer joins that will occasionally force you to use the old form.
Still, I find that it can improve the maintainability of SQL - especially with careful formatting:
select member.*,
member_customer.* from member m
left outer join member_customer mc
on mc.id = mc.id
and mc.customer_id = 1
left outer join member_supplier ms
on mc.id = ms.id
left outer join member_preferences mp
on mc.id = mp.id where m.state = 'IL'
I would rather see programmers develop expertise in standard SQL than in any one variant for the vast majority of cases.
Sure, query optimization is a possible downside to placing such a priority upon standardization, but then again query optimization isn't everything - nor is it necessarily best addressed through proprietary SQL extensions. Portability, maintainability, adaptability, future-proofing against changes to the optimizer in later versions - are all additional reasons to avoid proprietary extensions when standard SQL will work fine.
I've been here before - and there's more to consider than just billing rates and communication challenges.
One issue that seldom comes to light is that the increased communication requirements pretty much force you to use antiquated DoD-style waterfall methodlogies. These methodologies are notoriously slow, expensive, and failure-prone.
An alternative is an agile methology - such as RAD, XP, etc, etc. However - it's highly unlikely that you'll be successful with this kind of methodology being performed by an offshore agency.
My money is on a small, talented team using an agile methodology vs a large offshore team using waterfall. In fact, I'd give some pretty good odds on it!
I will never forget how they wanted my project to use E10Ks instead of Sequents a few years back. The Sequents beat the bajesus out of the E10Ks for scalability, so Sun kept telling folks that they had some breakthrough documents that really dispelled the NUMA architecture. When forced to reveal them they were 4 years old and described the alpha imlementation!
BTW, I've never worked with a hardware vendor who stooped that low before or since. Of course, database vendors are another story thanks to Oracle and Sybase!
Slashdot Mirror
It's sad how all criticisms of MySQL on slashdot are consistently modded down. Although MySQL is a fine product with a lot going for it - there is plenty to be *legitimately* critical about.
Is it that the MySQL supporters on slashdot are only familar with application programming interfaces to relational databases - and so don't understand the differences between a modern relational database and MySQL? Or are they simply pushing the product that they are most familiar with?
I've been involved in purchases of millions of dollars in relational database software over the last sixteen years; been a DBA on Oracle, Informix, and DB2; and developed on those as well as Sybase, SQL Server, Adabas (SAP-DB), Dbase IV, and Access. And I can say that there are plenty of traditional IT applications that I would try Postgresql out on - just about everything in the OLTP arena that doesn't require massive scalability. And unfortunately, there are far fewer traditional IT database applications that I would recommend MySQL for - it simply lacks too many features that are already available in postgresql, and that in the RealWorld(tm) save your bacon.
Ok, you can mod me down now.
In addition to looking for spam you could use this approach to initially filter your valid email into various topical inboxes.
So, with some modifications it could move all the mail you get from work, from various hobby/educational/professional listserves and put them into separate folders for you to scan.
I'd find this tremendously useful, and it would probably even enable me to subscribe to a few more listserves - without the worry of being buried in the resulting email.
So, security benefits from a strategy in which it fails gracefully, and is best implemented in small, easily manageable pieces?
And security also benefits from a reliance upon complex (human) intelligence instead of simplistic boolean concepts of success/fail?
Hmmm, doesn't that sound like just about every other kind of system in the world? Whether we're talking about how to build elegant systems that fail gracefully, or how to build systems that deliver what you want rather than what is easy, there are examples all around us.
However, if we look farther ahead and we will see another set of problems. For example, a reliance upon humans to evaluate system performance (whether the system is a security system or a telephone network) is expensive and is also unreliable. One of the next steps is SPC - where we can provide tools to help the humans automate much of the drudgery of looking through gazillions of bytes of low-level information.
MCI always paid as late as possible, and I heard that Worldcom often simply didn't pay many of its creditors.
The funny part about this is that last year they were looking for ways to save money - and decided to go with cheaper coffee in one of their largest facilities.
So, Worldcom failed to integrate the sixty companies that they acquired - and their operations were bleeding money like an arterial wound. Additionally, they had overspent on MCI by about $10 billion, and had $7 billion +
hidden in accounting gimmicks --- but thank god they saved $400 a year on cheap coffee.
just another 'decision made at internet speed' I suppose.
The problem with putting 100% of the business logic in the middle tier dogma is that most folks saying this haven't sufficiently tested it.
.NET.
Aside from the valid and well-known disadvantages to implementation within the database, the following advantages are unfortunately not well known to having a logical application layer constructed from stored procedures & views:
#1: database technology typically outlasts application technology. So - business logic implemented in T/SQL or PL/SQL in 1994 still runs perfectly fine today. If it had been implemented in pro/c it would have them probably been re-implemented in VB, then C/CGI, then perhaps Perl, then Java, and now
#2: physical tuning. Databases physical schemas often have to be changed to deal with changing performance needs. If the interface from the application layer to the database is through a stored procedure the entire change can be implemented by a DBA. On the other hand, if the application is using selects/deletes/updates on the database a physical schema change will generally require a combined effort of programmers and DBAs - and suddenly become a significant project.
#3 Adaptability. Similar to the above issue, logic within the database allows the DBA to re-engineer the physical schema to one with greater flexibility without impacting the interface to existing applications. The alternative typically involves duct-tape-and-bailing wire to ensure minimal impact to existing application code.
#4 Capability. Some database modeling patterns involve the use of tree and network patterns that allow tons of flexibility but poor performance for scanning queries. The poor performance can be addressed with triggers that also insert to read-only tables. This capability provides extrordinarily flexible, adaptable, and reusable schemas, with no performance disadvantages. But - it is practically impossible if you are doing selects/deletes/inserts from the application layer.
So, yeah 'common knowledge' says that you need to use just a subset of database functionality, and move everything into a middle application layer. Then again 'common knowledge' in 1994 said that client-server was the future of database architectures. And quite a few projects suffered because of the parrots that endlessly repeated the dogma/mantra that client-server was best. Business logic in the middle-tier is the exact same thing.
I continually hear mysql folks repeat the dogma that it is faster than the commercial alternatives - but I've *never* seen a benchmark that backed this up - and wasn't trivial. Can anyone point to something beyond the home hobbiest level?
Since these days OLAP & warehousing are *core* functionality, any database that cannot provide at least nominal capabilities in this area isn't a serious contender beyond the web boutique/minor league applications.
Although some analytical functionality is needed today within most OLTP applications (summary tables, search tables, simplistic report tables, etc), a pure OLAP/Warehousing benchmark would be the easiet to compare to commercial alternatives.
So, how about something along the lines of TPCDs - representing, say, a 300 gbyte reporting application with dimensional tables.
Oracle, DB2, Informix, and Sybase easily delver solutions for this with support for partitioning, unions, parallelism, bitmap indexes, etc. SQL Server can as well, just to a lesser extent.
But, have any benchmarks - or success stories established that mysql is even a player in this space? Or is this just another popular delusion?
Nobody wears gloves to prevent their fingerprints from being recorded without their permission.
Then again - there's no way to perform that cheaply and easily.
But Mega-Corp, with its 100,000 employees could probably very easily have another company score its employees on likelihood of having smoked, used drugs, etc - all based on changes to retina images.
Why should you care if you're innocent? Hmmm, where have we heard that before.
I use both join forms with SQL Server, and have finally gotten used to the explicit form. However, the Microsoft implementation is less than perfect:
- you can't use derrived tables
- you can't group one table and then join it to another
- there are also limitations in how you can use outer joins that will occasionally force you to use the old form.
Still, I find that it can improve the maintainability of SQL - especially with careful formatting:
select member.*,
member_customer.*
from member m
left outer join member_customer mc
on mc.id = mc.id
and mc.customer_id = 1
left outer join member_supplier ms
on mc.id = ms.id
left outer join member_preferences mp
on mc.id = mp.id
where m.state = 'IL'
I would rather see programmers develop expertise in standard SQL than in any one variant for the vast majority of cases.
Sure, query optimization is a possible downside to placing such a priority upon standardization, but then again query optimization isn't everything - nor is it necessarily best addressed through proprietary SQL extensions. Portability, maintainability, adaptability, future-proofing against changes to the optimizer in later versions - are all additional reasons to avoid proprietary extensions when standard SQL will work fine.
I've been here before - and there's more to consider than just billing rates and communication challenges.
One issue that seldom comes to light is that the increased communication requirements pretty much force you to use antiquated DoD-style waterfall methodlogies. These methodologies are notoriously slow, expensive, and failure-prone.
An alternative is an agile methology - such as RAD, XP, etc, etc. However - it's highly unlikely that you'll be successful with this kind of methodology being performed by an offshore agency.
My money is on a small, talented team using an agile methodology vs a large offshore team using waterfall. In fact, I'd give some pretty good odds on it!
Ken Farmer
In my experience it's about 1/2 of their R&D.
I will never forget how they wanted my project to use E10Ks instead of Sequents a few years back. The Sequents beat the bajesus out of the E10Ks for scalability, so Sun kept telling folks that they had some breakthrough documents that really dispelled the NUMA architecture. When forced to reveal them they were 4 years old and described the alpha imlementation!
BTW, I've never worked with a hardware vendor who stooped that low before or since. Of course, database vendors are another story thanks to Oracle and Sybase!