If you'd ever worked in the military, you'd know just how meaningless that sentence really is. I already linked to the famous case of Major General Albert Stubblebine - if that's not enough to convince you that crazy people slip through the cracks, then I don't know what will.
Re-read what I said. You're arguing that because crazy people can slip through the cracks, the only possible explanation is that all people you disagree with are therefore crazy. That, bluntly, is crazy.
Honestly, at least one of them has been established as both sane and extremely credible. Generally they have all been given a thumbs up. Regardless, they may all be crazy. I don't know. And factually, you don't know either. But as I originally stated, your argument doesn't indicate anything other than your belief in irrational and illogical argument to establish an equally false position. As such, your dismissal of the reports is nothing but hand waving masquerading as rational debate.
No, I'm saying that no one could be a credible witness to a UFO.
Ummm....You just took a left turn into crazy town there.
Go read what the definition of an UFO. Anyone can be a credible witness of a UFO. Period. The only thing which requires credibility beyond seeing a UFO are possible implications or cause and effect which people assert may have a association with the UFO in question.
Factually, anything can be a UFO. For example, a UFO can be a plane; albeit unrecognizable as a plane to the observer. Someone saying they saw an object in the sky but could not describe it as a plane has factually seen a UFO. Period. Using your logic, no one can be a credible witness to anything. That's just dumb.
The UN has no forces. All UN forces are actually forces of other countries. So for example, the UN Air Force is likely to be US Air Force, German Air Force, Japan...so on and so on...
I completely agree with your point, but despite their reports at the time, the government and the military did not consider them crazy. In fact, at least one of them was given additional access to nukes and broader authority over our national defense. Furthermore, these are all people who are constantly monitored and evaluated. You can say many things, but crack pot is not one of them.
Basically, your dismissal is invalid as everyone who can assign authority has done so for at least one of them. In fact, using your own logic, comparing you against at least one of them, means you are far, far more likely to be a crazy nut job in comparison. Therefore, we shouldn't listen to your position in the least.
To be clear, while I agree with your general position, in this case, its not really applicable. And if its not applicable to at least one, your hand waving and ready dismissal is without justification. They may be crackpots, but not by your argument and rational.
Ceramics are now actively being explored by a small but growing number of physicists, chemists, and materials engineers.
As a side, seriously doubt such claims as combining metals to form different alloys is actually pretty easy to do, even by nature. Different types of ceramics are still fairly difficult even by today's standards and frequently require tools such as scanning electron microscopes. And for as long as we've been doing that, metallurgy didn't really take off into big science until maybe three or four decades ago; much of which stems from improve tank armor and plane materials, and out growth from there.
Theoretical physicists currently agree FTL is at least theoretically possible albeit improbable. They also agree there is a hell of a lot of physics we don't even begin to understand. Hell, we're still looking for basic players to explain the most fundamental abstracts of the physics we think we have a fairly strong grasp of and that in turn directly points to not understand even a hell of a lot more.
Anyone who says its impossible lacks any and all credible proof. Those that say it may, one day, be at least possible, are supported by the physics we know and understand today.
I assume he means both manned and unmanned travel and is likely including the moon. We now have man made objects outside of the solar system so technically we have achieved interstellar travel - just not in the way we'd all recognize from scifi and TV.
"But Mr. President we saved USD100M by hiring Indian programmers, which was late one year, whereby we then had to double our effort to fix all of the poor quality code resulting in an overage of roughly 2x what it would have cost to done it right and on time in the first place."
I'm very skeptical of the claim that in this century, unions help pay, or that right-to-work states have lower pay.
Its extremely likely not true in the least, unless you compare union wages against non-union wages, which is likely the basis for such a comparison. Its pretty well established union wages are almost always higher than non-union wages.
As a result of unions, non-union jobs are almost always the first to suffer. Unions use it as an excuse to justify membership and to entice new members. In reality, they are using their own existence to justify membership as those jobs would likely never be endangered if it were not for the union in the first place.
For example: you could not go to a convenience store and withdraw money from your bank account and get cash right there, before the convenience stores started buying and operating ATMs, to get surcharge $$$ for the service.
History says you are absolutely wrong. Period.
More accurately, banks were rolling out ATMs because it prevented the need for new banks and allowed them to downsize existing banks. Many/most banks already had the communication infrastructure (credit & debit card, ACH, etc), or planning to implement, to support these new financial transactions. They already had an incentive to roll out lots of ATMs; and were doing so. How many ATMs do you think you can roll out across the nation for the cost of one bank building and one years operating expense? Exactly.
I worked in banking (electronic transactions) during this period when ATMs were starting their roll out.
The fact that its a competition is dumb. The fact they are doing it is very much cause for concern. Supercomputers affect everything around either directly or indirectly. With powerful enough super computers you can simulate and create better nuclear warheads and delivery devices, better power plants, better fuels/explosives (this means, rockets, missiles, firearms, artillery), better chemistry for medical use, better lasers, better planes (including fighters and bombers), stealth technology, better integrated computing, so on and so on. Of course, this also means better physics and education.
Literally, better supercomputers means almost everything related to high tech warfare to high tech industry becomes dramatically more accessible. So contrary to the notion that a superior supercomputer only garners national pride, it means a whole lot more. It means the balance of energy, industry, technology, physics, medicine, and potentially endless technological breakthroughs.
Without supercomputers, many of the nukes in the US arsenal would actually be dirty bombs or much lower yield nukes. Supercomputers allow us to replace potentially worrisome devices to ensure their effectiveness. Supercomputers are also used to improve existing nuclear power plant designs as well as to research designs of tomorrow. Supercomputers play key roles in advanced research projects like the LHC and particle physics. Particle physics plays a huge role in better rocket fuels, explosives, rocket engines, and even jet engines. Supercomputers are also used to model electron interaction for new types of integrated circuitry and even CPU simulation (develop and test before you actually build hardware).
Supercomputers may be a measure of pride, but most of all, they are a measure of a nation's technological capabilities and aspirations for tomorrow.
It may have been. But since you've never looked back, it may not, and is likely, no longer true. If its good enough, its good enough, but bragging doesn't normally center around the notion of "good enough."
My broader point was not to knock PostgreSQL, only to make the point that MySQL does not deserve the reputation it has in certain quarters, particularly among PostgreSQL advocates.
Hate to tell you, but it has a universally poor reputation amongst the majority of high end RDBMS DBAs. In other words, the same group which typically has high regard for most of its competition, including MS SQL Server, frequently has a very low regard for MySQL. This alone should be reason enough to wonder why that might possibly be.
The fact this idiotic post was moderated "insightful" is fucking scary. Other posts I can respect someone who may have your wayward point of view. But that post - complete stupidity and nothing but troll. The fact that it was moded up means either you have another account with mod points (very, very, very likely) or that we can now easily confirm/. has absolute fucking idiots with mod points.
After thinking of it - there may well be an intersection here.
When have you ever seen a bank charge their customers to use the ATM?
They still exist, though fairly rare for on network transactions.
3rd party ATM network operators offer ATM withdrawls as a service with a surcharge,
ATM transactions save them money. The ONLY reason they charge a surcharge is because they lobbied Congress to allow them to do so. They were already making money by spending less. Which do you think costs more? A bank building with tellers inside or a dumb box and phone line? There is zero legitimate reason to ever charge an ATM fee. They simply make money over and above their massive savings.
Remember, ATMs were already appearing everywhere before the surcharge was legalized (there was no surcharge). Why would they do this if there was a loss? Here's a hint, ATMs have always been a competitive advantage and huge savings for banks. In turn, they take load off of actual banks and their tellers, allowing them to have far fewer tellers.
Basically, they have legalized charging you to access your money, to which you've loaned them which allows them to make money in the first place.
This is because MySQL and PostgreSQL are in the same class.
But that's the thing. Everyone except MySQL fans insist they are not. MySQL is squarely in a class of its own. Its somewhere between Access and all the other big-boy databases; which includes PostgreSQL. This is why there is constantly so much push back from everyone else who has used grown up databases and had a need for their features.
I'm not advocating PostgreSQL is a database for all datasets and use cases. It absolutely is not. Just the same, MySQL isn't even close to being in the same class with PostgreSQL or any of the other big-boy databases.
MySQL is the big block Gremlin which is constantly interjected into conversations about Ferraris, Porches, and Lamborghinis. Sure a Gremlin can be really fast, but no matter what you do, its still not even close to being in the same class.
There - my car analogy quota for the day is complete.
You clearly have little experience with MySQL. Look, I understand your smugness and arrogance.
Whoosh!!
This isn't smugness or arrogance. Seriously, think about it. If you heard someone bragging about using x because its faster than y, despite y now being much better than x almost immediately after the selection x, you would enjoy the humor. That's what this boils down to.
As you then went on to boast you've never looked back, additional information was provided so you could realize that you really should be looking back to at least re-evaluate if your braggart position is still viable.
If you don't want to look back, that's fine, but don't get upset when your position puts a smile on other's faces.
The reviews I've read have all been very favorable from a performance perspective. As you point out, simple row triggers which work on every row won't see much of a performance advantage, if any. The entire focus in my comments have been for large, complex triggers which frequently branch based on column evaluation. This is the environment in which column triggers can deliver big returns, especially in the cases where after lots of evaluation and branches, it turns out no work on the row is to be done.
I did not mean to imply this will improve performance for everyone, without consideration. Hopefully you didn't get that impression. It clearly will not. But for many systems which are built around the database and have complex triggers, column triggers can be a real silver bullet given the right work load.
Its extremely ironic that you changed just as PostgreSQL become considerably faster than MySQL. PostgreSQL has always been far more scalable. To now hear you brag that you've never looked back at a superior and faster database because of your steadfast and likely false belief that MySQL is faster, is rather amusing.
One of the biggest problems with the MySQL user base is that they don't have any idea what "faster" means nor do they typically understand how to benchmark. Made worse, they constantly confuse speed with scalability. And made ever worse, most MySQL users take the MySQL benchmarks to heart when time and time again they are nothing but marketing lies. Most independent tests have historically had lots of problems even getting MySQL to stay running until the end. And when it actually does finish, its normally somewhere between the middle of the pack to dead last - and that's with all the other databases forced to use the lowest common feature which prevents them from using their advanced, much, much faster features.
The bottom line is, MySQL is popular because it has buzzword compliance for people who almost always don't know any better; but most of all, was readily available on Windows at a time when everyone was looking for a free database to go to. PostgreSQL is popular because it has both buzzword compliance, is far more feature rich, almost always out performs MySQL, and underscores, not to mention truly understands, what ACID is all about - while providing a very rich set of features which MySQL is unlikely to ever match. And that's ignoring that MySQL's optimizer absolutely stinks for anything but the most simple of queries.
The best rule of thumb is, think of MySQL as a really fast Access database. If you wouldn't use Access, ignoring database performance in the comparison, you should think really hard about using MySQL. There are so many superior and still free RDBMs compared to MySQL, its easy to see why so many get so frustrated when others insist on injecting an dramatically inferior solution into the equation, just because it has buzzwords.
Actually, you need to take a closer look. Your argument completely agrees with everything I'm saying.
If they have extremely simplistic optimizations, its impossible for them to be competitive. Period.
If they the checks you recommend, the provided code would have zero affect on runtime, other than parsing and code generation, and executing of a single, nop instruction. Which isn't likely to account for more than a fraction of a ms.
You also need to take a closer look at the example provided. This has zero to do with loop evaluation. Placing an implicit return outside of a loop is not going to affect code generation at all. Placing a "true;" above the loop, at worse, is going to allocate an anonymous variable which is never referenced. If returning, which it always, already has to do costs 22x in performance, it is literally impossible for IE to ever be competitive with other browsers - ever! Period. At yet they clearly are competitive in the benchmark so we can assume this isn't a fundamental JS return/optimization problem.
Thusly, the ONLY possible, reasonable conclusion is that MS is cheating their asses off in these benchmarks.
Basically, most everyone that replied, and the moderators, are idiots and have no fucking idea what the subject matter is, let alone capable of understanding what it is they read.
YOU are the reason why so many projects require complete rewrites when a single feature is added or removed or altered.
You really have no idea what you're talking about do you.
That's entirely the point of doing it inside the database. By doing it your way, you are ensuring that everything outside of the database must be changed, including all applications. Or, you can do it inside the database, update one trigger, and everything continues to run, bug/error free.
In other words, what you advocate is well known to be the completely wrong way to do things. Basically, your way is the absolute best possible way anyone can go about creating the exact problem you accuse others of creating by doing it properly. Basically you're proving you are completely ignorant of the subject matter. Worse, you're proving in 20 years of experience, you've not learned how to do it right - which is extremely scary. If this was twenty years ago, you might get people to buy into your BS, but this day in age, anyone skilled with databases and application development is not going to want to have anything to do with your horrible and frankly, idiotic, suggestions.
The recommended practice - create and maintain in one place. Debug one. Test once. Fixing requires on place. Your recommendation - create and maintain in unlimited locations. Debug everywhere. Test everywhere. Basically, world's dumbest fucking idea.
There is a difference between the engine checking a constraint versus a call into an interpreted language. One is doing less work. The other is doing more work. Which is ideal? Obviously less work is better. And that's before you even get into the PL/SQL code which is essentially doing the same work, but slower. Furthermore, all too often, triggers are called when there is no work to be done but you don't know that until the PL code decides this is the type of row change its interested, otherwise it should have really been a NOP. Whereas with the column trigger, the call to the PL code simply never takes place. So we not only save on the call but all of the wasted time inside of a trigger which ultimately decides its has nothing to do.
Also, when the trigger should be called, in a row trigger, triggers frequently must evaluate which columns have changed before it can even determine if it cares about this row. Should it then decide it does care about this row, likely you've already passed through a mass of CASE and/or IF/THEN/ELSE codes, which ultimately states yet more CASE and/or IF/THEN/ELSE to determine exactly what it should now be doing now that its decided it does need to process this row. Or, you can call a much smaller section of code which is dramatically simplified because one, its only called when its pre-qualified (saving the creation of much redundant code) and two, since its now pre-qualified, we can immediately get to performing whatever logic the trigger in question should do when the column in question has changed.
Those are worlds apart in performance, readability, maintainability. Not to mention the added granularity makes possible a reduction in the test matrix, regression tests, and even makes it more difficult (though far from impossible) to create a regression.
You clearly have no idea what you're talking about. Granularity is widely accepted for such linguistic applications. The reason being, its completely applicable.
Basically you're foolishly arguing that monster triggers are preferred over small, terse, highly readable, and much more maintainable triggers. Lots and lots of code is good. Less code which does the same thing is bad. That's simply ignorant, foolish, and FUD. "Scattering" is clearly being used to imply a negative connotation. Given there isn't a single negative with their use and that "granularity" is accepted and proper, making such statements squarely implies you're trolling.
Slashdot Mirror
If you'd ever worked in the military, you'd know just how meaningless that sentence really is. I already linked to the famous case of Major General Albert Stubblebine - if that's not enough to convince you that crazy people slip through the cracks, then I don't know what will.
Re-read what I said. You're arguing that because crazy people can slip through the cracks, the only possible explanation is that all people you disagree with are therefore crazy. That, bluntly, is crazy.
Honestly, at least one of them has been established as both sane and extremely credible. Generally they have all been given a thumbs up. Regardless, they may all be crazy. I don't know. And factually, you don't know either. But as I originally stated, your argument doesn't indicate anything other than your belief in irrational and illogical argument to establish an equally false position. As such, your dismissal of the reports is nothing but hand waving masquerading as rational debate.
No, I'm saying that no one could be a credible witness to a UFO.
Ummm....You just took a left turn into crazy town there.
Go read what the definition of an UFO. Anyone can be a credible witness of a UFO. Period. The only thing which requires credibility beyond seeing a UFO are possible implications or cause and effect which people assert may have a association with the UFO in question.
Factually, anything can be a UFO. For example, a UFO can be a plane; albeit unrecognizable as a plane to the observer. Someone saying they saw an object in the sky but could not describe it as a plane has factually seen a UFO. Period. Using your logic, no one can be a credible witness to anything. That's just dumb.
The UN has no forces. All UN forces are actually forces of other countries. So for example, the UN Air Force is likely to be US Air Force, German Air Force, Japan...so on and so on...
I completely agree with your point, but despite their reports at the time, the government and the military did not consider them crazy. In fact, at least one of them was given additional access to nukes and broader authority over our national defense. Furthermore, these are all people who are constantly monitored and evaluated. You can say many things, but crack pot is not one of them.
Basically, your dismissal is invalid as everyone who can assign authority has done so for at least one of them. In fact, using your own logic, comparing you against at least one of them, means you are far, far more likely to be a crazy nut job in comparison. Therefore, we shouldn't listen to your position in the least.
To be clear, while I agree with your general position, in this case, its not really applicable. And if its not applicable to at least one, your hand waving and ready dismissal is without justification. They may be crackpots, but not by your argument and rational.
Ceramics are now actively being explored by a small but growing number of physicists, chemists, and materials engineers.
As a side, seriously doubt such claims as combining metals to form different alloys is actually pretty easy to do, even by nature. Different types of ceramics are still fairly difficult even by today's standards and frequently require tools such as scanning electron microscopes. And for as long as we've been doing that, metallurgy didn't really take off into big science until maybe three or four decades ago; much of which stems from improve tank armor and plane materials, and out growth from there.
Theoretical physicists currently agree FTL is at least theoretically possible albeit improbable. They also agree there is a hell of a lot of physics we don't even begin to understand. Hell, we're still looking for basic players to explain the most fundamental abstracts of the physics we think we have a fairly strong grasp of and that in turn directly points to not understand even a hell of a lot more.
Anyone who says its impossible lacks any and all credible proof. Those that say it may, one day, be at least possible, are supported by the physics we know and understand today.
I assume he means both manned and unmanned travel and is likely including the moon. We now have man made objects outside of the solar system so technically we have achieved interstellar travel - just not in the way we'd all recognize from scifi and TV.
"But Mr. President we saved USD100M by hiring Indian programmers, which was late one year, whereby we then had to double our effort to fix all of the poor quality code resulting in an overage of roughly 2x what it would have cost to done it right and on time in the first place."
Fixed that for you.
I'm very skeptical of the claim that in this century, unions help pay, or that right-to-work states have lower pay.
Its extremely likely not true in the least, unless you compare union wages against non-union wages, which is likely the basis for such a comparison. Its pretty well established union wages are almost always higher than non-union wages.
As a result of unions, non-union jobs are almost always the first to suffer. Unions use it as an excuse to justify membership and to entice new members. In reality, they are using their own existence to justify membership as those jobs would likely never be endangered if it were not for the union in the first place.
Is this legal, even in the US?
Doubtful. But do you want to be the one that foots the legal bill? For even such a simple matter, it could stretch on for a year or more.
For example: you could not go to a convenience store and withdraw money from your bank account and get cash right there, before the convenience stores started buying and operating ATMs, to get surcharge $$$ for the service.
History says you are absolutely wrong. Period.
More accurately, banks were rolling out ATMs because it prevented the need for new banks and allowed them to downsize existing banks. Many/most banks already had the communication infrastructure (credit & debit card, ACH, etc), or planning to implement, to support these new financial transactions. They already had an incentive to roll out lots of ATMs; and were doing so. How many ATMs do you think you can roll out across the nation for the cost of one bank building and one years operating expense? Exactly.
I worked in banking (electronic transactions) during this period when ATMs were starting their roll out.
The fact that its a competition is dumb. The fact they are doing it is very much cause for concern. Supercomputers affect everything around either directly or indirectly. With powerful enough super computers you can simulate and create better nuclear warheads and delivery devices, better power plants, better fuels/explosives (this means, rockets, missiles, firearms, artillery), better chemistry for medical use, better lasers, better planes (including fighters and bombers), stealth technology, better integrated computing, so on and so on. Of course, this also means better physics and education.
Literally, better supercomputers means almost everything related to high tech warfare to high tech industry becomes dramatically more accessible. So contrary to the notion that a superior supercomputer only garners national pride, it means a whole lot more. It means the balance of energy, industry, technology, physics, medicine, and potentially endless technological breakthroughs.
Without supercomputers, many of the nukes in the US arsenal would actually be dirty bombs or much lower yield nukes. Supercomputers allow us to replace potentially worrisome devices to ensure their effectiveness. Supercomputers are also used to improve existing nuclear power plant designs as well as to research designs of tomorrow. Supercomputers play key roles in advanced research projects like the LHC and particle physics. Particle physics plays a huge role in better rocket fuels, explosives, rocket engines, and even jet engines. Supercomputers are also used to model electron interaction for new types of integrated circuitry and even CPU simulation (develop and test before you actually build hardware).
Supercomputers may be a measure of pride, but most of all, they are a measure of a nation's technological capabilities and aspirations for tomorrow.
+1 Insightful.
I completely missed that until you pointed it out. Good call.
I knew there was a reason I +1 Insightful' ed you before. ;)
It was the right decision for us.
It may have been. But since you've never looked back, it may not, and is likely, no longer true. If its good enough, its good enough, but bragging doesn't normally center around the notion of "good enough."
My broader point was not to knock PostgreSQL, only to make the point that MySQL does not deserve the reputation it has in certain quarters, particularly among PostgreSQL advocates.
Hate to tell you, but it has a universally poor reputation amongst the majority of high end RDBMS DBAs. In other words, the same group which typically has high regard for most of its competition, including MS SQL Server, frequently has a very low regard for MySQL. This alone should be reason enough to wonder why that might possibly be.
The fact this idiotic post was moderated "insightful" is fucking scary. Other posts I can respect someone who may have your wayward point of view. But that post - complete stupidity and nothing but troll. The fact that it was moded up means either you have another account with mod points (very, very, very likely) or that we can now easily confirm /. has absolute fucking idiots with mod points.
After thinking of it - there may well be an intersection here.
When have you ever seen a bank charge their customers to use the ATM?
They still exist, though fairly rare for on network transactions.
3rd party ATM network operators offer ATM withdrawls as a service with a surcharge,
ATM transactions save them money. The ONLY reason they charge a surcharge is because they lobbied Congress to allow them to do so. They were already making money by spending less. Which do you think costs more? A bank building with tellers inside or a dumb box and phone line? There is zero legitimate reason to ever charge an ATM fee. They simply make money over and above their massive savings.
Remember, ATMs were already appearing everywhere before the surcharge was legalized (there was no surcharge). Why would they do this if there was a loss? Here's a hint, ATMs have always been a competitive advantage and huge savings for banks. In turn, they take load off of actual banks and their tellers, allowing them to have far fewer tellers.
Basically, they have legalized charging you to access your money, to which you've loaned them which allows them to make money in the first place.
This is because MySQL and PostgreSQL are in the same class.
But that's the thing. Everyone except MySQL fans insist they are not. MySQL is squarely in a class of its own. Its somewhere between Access and all the other big-boy databases; which includes PostgreSQL. This is why there is constantly so much push back from everyone else who has used grown up databases and had a need for their features.
I'm not advocating PostgreSQL is a database for all datasets and use cases. It absolutely is not. Just the same, MySQL isn't even close to being in the same class with PostgreSQL or any of the other big-boy databases.
MySQL is the big block Gremlin which is constantly interjected into conversations about Ferraris, Porches, and Lamborghinis. Sure a Gremlin can be really fast, but no matter what you do, its still not even close to being in the same class.
There - my car analogy quota for the day is complete.
You clearly have little experience with MySQL. Look, I understand your smugness and arrogance.
Whoosh!!
This isn't smugness or arrogance. Seriously, think about it. If you heard someone bragging about using x because its faster than y, despite y now being much better than x almost immediately after the selection x, you would enjoy the humor. That's what this boils down to.
As you then went on to boast you've never looked back, additional information was provided so you could realize that you really should be looking back to at least re-evaluate if your braggart position is still viable.
If you don't want to look back, that's fine, but don't get upset when your position puts a smile on other's faces.
The reviews I've read have all been very favorable from a performance perspective. As you point out, simple row triggers which work on every row won't see much of a performance advantage, if any. The entire focus in my comments have been for large, complex triggers which frequently branch based on column evaluation. This is the environment in which column triggers can deliver big returns, especially in the cases where after lots of evaluation and branches, it turns out no work on the row is to be done.
I did not mean to imply this will improve performance for everyone, without consideration. Hopefully you didn't get that impression. It clearly will not. But for many systems which are built around the database and have complex triggers, column triggers can be a real silver bullet given the right work load.
Its extremely ironic that you changed just as PostgreSQL become considerably faster than MySQL. PostgreSQL has always been far more scalable. To now hear you brag that you've never looked back at a superior and faster database because of your steadfast and likely false belief that MySQL is faster, is rather amusing.
One of the biggest problems with the MySQL user base is that they don't have any idea what "faster" means nor do they typically understand how to benchmark. Made worse, they constantly confuse speed with scalability. And made ever worse, most MySQL users take the MySQL benchmarks to heart when time and time again they are nothing but marketing lies. Most independent tests have historically had lots of problems even getting MySQL to stay running until the end. And when it actually does finish, its normally somewhere between the middle of the pack to dead last - and that's with all the other databases forced to use the lowest common feature which prevents them from using their advanced, much, much faster features.
The bottom line is, MySQL is popular because it has buzzword compliance for people who almost always don't know any better; but most of all, was readily available on Windows at a time when everyone was looking for a free database to go to. PostgreSQL is popular because it has both buzzword compliance, is far more feature rich, almost always out performs MySQL, and underscores, not to mention truly understands, what ACID is all about - while providing a very rich set of features which MySQL is unlikely to ever match. And that's ignoring that MySQL's optimizer absolutely stinks for anything but the most simple of queries.
The best rule of thumb is, think of MySQL as a really fast Access database. If you wouldn't use Access, ignoring database performance in the comparison, you should think really hard about using MySQL. There are so many superior and still free RDBMs compared to MySQL, its easy to see why so many get so frustrated when others insist on injecting an dramatically inferior solution into the equation, just because it has buzzwords.
Actually, you need to take a closer look. Your argument completely agrees with everything I'm saying.
If they have extremely simplistic optimizations, its impossible for them to be competitive. Period.
If they the checks you recommend, the provided code would have zero affect on runtime, other than parsing and code generation, and executing of a single, nop instruction. Which isn't likely to account for more than a fraction of a ms.
You also need to take a closer look at the example provided. This has zero to do with loop evaluation. Placing an implicit return outside of a loop is not going to affect code generation at all. Placing a "true ;" above the loop, at worse, is going to allocate an anonymous variable which is never referenced. If returning, which it always, already has to do costs 22x in performance, it is literally impossible for IE to ever be competitive with other browsers - ever! Period. At yet they clearly are competitive in the benchmark so we can assume this isn't a fundamental JS return/optimization problem.
Thusly, the ONLY possible, reasonable conclusion is that MS is cheating their asses off in these benchmarks.
Basically, most everyone that replied, and the moderators, are idiots and have no fucking idea what the subject matter is, let alone capable of understanding what it is they read.
YOU are the reason why so many projects require complete rewrites when a single feature is added or removed or altered.
You really have no idea what you're talking about do you.
That's entirely the point of doing it inside the database. By doing it your way, you are ensuring that everything outside of the database must be changed, including all applications. Or, you can do it inside the database, update one trigger, and everything continues to run, bug/error free.
In other words, what you advocate is well known to be the completely wrong way to do things. Basically, your way is the absolute best possible way anyone can go about creating the exact problem you accuse others of creating by doing it properly. Basically you're proving you are completely ignorant of the subject matter. Worse, you're proving in 20 years of experience, you've not learned how to do it right - which is extremely scary. If this was twenty years ago, you might get people to buy into your BS, but this day in age, anyone skilled with databases and application development is not going to want to have anything to do with your horrible and frankly, idiotic, suggestions.
The recommended practice - create and maintain in one place. Debug one. Test once. Fixing requires on place.
Your recommendation - create and maintain in unlimited locations. Debug everywhere. Test everywhere. Basically, world's dumbest fucking idea.
There is a difference between the engine checking a constraint versus a call into an interpreted language. One is doing less work. The other is doing more work. Which is ideal? Obviously less work is better. And that's before you even get into the PL/SQL code which is essentially doing the same work, but slower. Furthermore, all too often, triggers are called when there is no work to be done but you don't know that until the PL code decides this is the type of row change its interested, otherwise it should have really been a NOP. Whereas with the column trigger, the call to the PL code simply never takes place. So we not only save on the call but all of the wasted time inside of a trigger which ultimately decides its has nothing to do.
Also, when the trigger should be called, in a row trigger, triggers frequently must evaluate which columns have changed before it can even determine if it cares about this row. Should it then decide it does care about this row, likely you've already passed through a mass of CASE and/or IF/THEN/ELSE codes, which ultimately states yet more CASE and/or IF/THEN/ELSE to determine exactly what it should now be doing now that its decided it does need to process this row. Or, you can call a much smaller section of code which is dramatically simplified because one, its only called when its pre-qualified (saving the creation of much redundant code) and two, since its now pre-qualified, we can immediately get to performing whatever logic the trigger in question should do when the column in question has changed.
Those are worlds apart in performance, readability, maintainability. Not to mention the added granularity makes possible a reduction in the test matrix, regression tests, and even makes it more difficult (though far from impossible) to create a regression.
You clearly have no idea what you're talking about. Granularity is widely accepted for such linguistic applications. The reason being, its completely applicable.
Basically you're foolishly arguing that monster triggers are preferred over small, terse, highly readable, and much more maintainable triggers. Lots and lots of code is good. Less code which does the same thing is bad. That's simply ignorant, foolish, and FUD. "Scattering" is clearly being used to imply a negative connotation. Given there isn't a single negative with their use and that "granularity" is accepted and proper, making such statements squarely implies you're trolling.