> We had a frequently used query against a sku > database on style, color, and size.
Love those apparel industry-specific systems and databases. There are reasons why they are designed the way they are (and different from everything else), but they are murderous to work with!
> Or you could put MySQL on an IBM Power Systems LPAR and use a commercial > MySQL plug-in [krook.net] to store the data in a DB2 database. Then you can > get away with maybe a dozen database machines instead of thousands. I have > to imagine, btw, that Oracle has a similar offering in the works.
Buh.. buh.. buh.. buh... But - that would be like a/mainframe/! Mainframes are archaic and obsolete - everyone knows that! How would you cluster the application servers to a system like that?!? _Everyone_ knows you need application servers!
> You write the code that actually does the queries as stored procedures > in the database, then write a DAL that essentially works as a database > driver. Your code does nothing to the DB other than requesting that it > execute an SP, and the SPs can be tuned for the specific database server.
True, but that is not writing "database independent code" - it is writing separate versions of the code for each database and building a good UI that can be configured to be compatible with all of the versions. That's exactly what Tom Kyte (of Oracle) recommends as a development strategy, and there is a funny case in _Tales of the Oak Table_ (a book I recommend to everyone involved with databases) where Oracle consultants called to a customer site ended up writing a second version of their customer's code for SQL Server, cleaning up the original version for Oracle, and having both be 100x faster than the original "independent" code with essentially the same total number of source code lines.
> Note that I've explicitly excluded Oracle from that list, as I've never once seen a > production Oracle database ever reach the performance of... well, any other > database server, really. I don't doubt that Oracle can be made fast; I just doubt > that getting the personnel who know how to do that and paying them to do so is > worth the cost compared to easier to use, less expensive, and faster out of the > box systems like, oh, DB2 and SQL Server.
We'll have to agree to disagree here. I agree there is some truth in what you say about needing people who actually understand Oracle; if it is installed and used as if it were Access then it doesn't work well. My personal experience however is more with an application running with decent performance on a single Oracle instance being replaced with a "cluster" of SQL Server that starts out with 10 machines (5 databases, 5 of whatever application server Microsoft is pushing this year) and ends up as a cluster(-f***) of 300 or more machines and a constant cry for "more RAM", "more budget", "more servers" - and is never as fast as the system it replaced.
> - a very clear definition of the problem, hence, the problem shouldn't be > too big (think a Wordpad sized project) > - a very thorough knowledge of the technology and its limitations (project > that works in several web browsers? forget it) > - almost no variation in deployment and use conditions > > Not many projects fall under those categories
And more generally: that is knowledge and wisdom that is typically only obtained by/doing the project/ - hands-on.
> Exactly, the thing with a SAP rollout (or anything else of this > magnitude) is that you pass the point of no return quite early > into the project and then the consultants have you exactly > where they want you
Here's a thought: consultants are there to do just that: train, guide, and consult (e.g. _assist_ with analyzing). The people doing the implementation should be the organization's managers (not "project managers" - managers) and the employees who will be using the system. Once a project of this type is segregated in the "IS Department" and handed over to "the consultants" it will certainly fail; the former may know what needs to be done but lack the authority to do it (hence the need for managers to be at the core) and the latter's perverse incentives and conflicts of interest are well documented.
> They would probably need to build an abstraction layer on top of MySQL. > Something like "FBSQL":) . This would create the ability to move to > whatever database system they want.
And get equal performance on all of them. Equally poor, that is.
> Far too often, vast ignorance, huge ego, and massive pride > prevent people from considering alternative database solutions > and their ignorance of the domain allows them to quickly > become self assured they've picked a winner.
I won't say that those factors don't come into play, because they do. But I think a more fundamental problem is that there has never been a good source of education on how relational databases really work in the corporeal world (as opposed to the theoretical world of CS 350), nor on how to develop scalable performant applications against databases as discussed by Tom Kyte and the Oak Table Group [1]. Instead just about everyone is self-taught, and unfortunately today that means self-taught with Microsoft Access and either MS SQL Server or MySQL - both of which lead to developing bad habits of thought [2] (autoincrementing columns! Yeah! Let's use them as primary keys!).
The somewhere around 2000 everyone decided that "application servers" and "database independent code" were the Wave of the Future(tm), and those without fundamental understanding followed along with the crowd. I have watched more than one performant single-instance Oracle-based application be replaced by a network of 327 servers running a competing RDBMS with the application becoming slower and less stable at ever step, yet it is Inconceivable(tm) to consider going back to the "archaic" design of a single powerful Oracle or DB2 instance with the majority of the business logic integrated into stored procedures. That's fad and fashion working against lack of true understanding, not just inflated ego.
sPh
[1] I'm sure there are other examples of good database design practice out there; those are the two I am most familiar with.
[2] Not that it isn't possible to build good systems with MS SQL Server, because it is possible. It just is rare in my experience.
> And, to add to that, Facebook is insane if they didn't implement > what is commonly called an "access layer" for abstraction, so > that the system can be rapidly ported from one RDBMS to another.
"Access layer" aka "database independence". Otherwise known as "absolute death to any hope of performance and scalability". The reason one pays large sums of money for an Oracle, DB2, or even SQL Server implementation and programming is _exactly_ to get the performance and scalability potential and improvements that only come from understanding what your code does in its actual operating environment. And that operating environment and its capabilities are different from product to product; otherwise why would there be more than one? Oracle and SQL Server, for example, use locking philosophies that are 123 degrees apart from one another - how the heck do you write performant code that works against both databases?
> The number of jetliners with "propellers" is mighty fucking few, though not zero.
The number of airliners with gas turbine engines that turn propellers is in fact quite large.
The bypass fan of a high-bypass turbofan engine is essentially a propeller as well, although ducted.
So that leaves us with the various 707s, DC-8s, and 727s and their military equivalents flying around out there with straight turbojet engines having no fan-push component, which is not all that many in 2011.
sPh
In any case the results of this study should have been blindingly obvious to anyone living in North America during the no-fly week of 9/11 - 9/18.
> . this means one of two things - Oracle are lying (believable)
Oracle are lying about what? There can't be more than a few hundred Itanium users around the world, and Intel has been signaling for years that the product line is dead and won't be replaced. Maybe HP shouldn't have shut down its own CPU development and sold its designs (along with the designs of the DEC Alpha) to Intel, but they did. Now that product line has failed and Oracle is just making an obvious business decision.
> Soft drinks used to be sold in glass bottles. It's been too long for me to > remember whether they were quart (~1 liter) or half-gallon (~2 liter) size, > but when the switch was made to plastic in the 80s, it was SI all the way.
The glass bottles were 64 oz (and IIRC only Coke used them; I don't recall any Pepsi products in that size). I used to stack the returns at the grocery store, and even empty they were heavy enough to beak your foot if you dropped one.
> 1) You are a true programmer, not just a code hack. You understand how a computer > actually thinks, how data is stored in memory, how a processor works, etc. You > understand that languages are just tools to do a job, and all they do is help you describe > to the computer what you wish it to do. If required you can pick up a new language with > little trouble because you understand it is all the same process, just different grammar > and syntax and so on.
I generally agree with that, and throughout the 80s and 90s it was a good strategy to use when fishing (as opposed to screening) for good candidates.
I'd still think hard about someone with solid varied experience. But as a technical manager who does a lot of work with databases and database-based applications I am forced to observe that there is a problem with people who have a lot of experience with Microsoft tools: they are often (not always, but often) damaged when it comes to working with databases. They don't understand database theory, they don't understand the practicalities of implementing performant database apps and managing databases in the real world, and they are absolutely wedded to thought processes (and architectural decisions) that lead to sub-optimal results. It just seems to be something that has come with working in Microsoft environments from about 2000 forward.
Admittedly the same thing often applies to those who have worked with nothing but Java, but the Java-heads are often (not always) re-programmable so to speak.
That's my 0.02 anyway. Could be wrong, but I have seen it again and again.
> The 50/60 Hz 100/90v division line in Japan dates to the year 1600 > and the battle of Seki-ga-hara [wikipedia.org]
The 50/60 Hz division in Japan dates to the point where Siemens salesmen happened to arrive at one end of the country and General Electric salesmen at the other end. Literally.
> GPS is a US government system on satellites, and > the receivers that give a position. Nothing more.
Actually, GPS is also a system that provides an extremely precise timing signal synchronized worldwide. I realize that the availability of such a signal is an essential ingredient of navigation, which is why the US Navy was originally going to call its satellite system "Navstar" (Nav = Navy = Navigation; I hope someday the real story of how the Air Force grabbed control of the project is told). But the precise timing signals, once made available, were and are used for many many things besides navigation. Operating continental electric grids is a good example.
> It has everything to do with all the other systems using GPS: the thing > that tracks the location of your important parcel, or keeps the "Next train in > 5 minutes" indicator accurate, or synchronises the clock on something.
Synchrophasor measurement units, which are being integrated into the power grid for a number of reasons ("smart" and old-fashioned operational as well), are heavily dependent on a GPS timing signal.
> You know, I thought you were serious until you put this part in. > Now I'm just laughing... We barely have "unmanned bombers" > now, much less in the 50's.
It was called Project Pluto, although IIRC there was a different name for the airplane/cruise missile that was to use the Pluto ramjet. After spending some time working on precision targeting systems, the designers realized that the weapon didn't need to hit any specific target; it just needed to fly back and forth over the enemy's terrain at low altitude where the combination of supersonic shock waves, direct radiation, and exhaust fallout would do more than enough damage. The autopilots of the 1950s were more than sufficient for that task.
The project was canceled in part due to concerns about its existence being overly proactive (as stated in the Wikipedia article), but also because the designers finally realized that even in the non-eco 1950s there would be nowhere on the planet that they could test it.
Um, why don't you send a notarized letter via certified post to your regional IP address manager (e.g. ARIN) describing the details under which you obtained the block and giving up any interest in same? If they need that block back it would at least give them a starting point to work with.
> There are major practical problems in making small high compression gas turbines > (among other things, conventional axial or centrifugal flow compressors do not > scale well to small sizes). The result is very poor fuel economy. Chrysler wasn't > the only manufacturer to build a gas turbine powered car. Rover built one in the > 1950's. At best these efforts demonstrated passable, but not exceptional performance > coupled with VERY high fuel consumption.
Not just automobile-sized turbines either; none of the experiments with turbine-powered locomotives in the 1950s and 60s were very successful; although the Union Pacific's (first deployed in 1948!) had plenty of power for the UP's long routes their fuel economy was so poor that they were only competitive when cheap low-grade fuel was available. When the price of even low-grade Bunker C went up after 1973 it was time for the scrap yard. The Norfolk & Western tried various arrangements of coal-burning turbines (both gasified and powered coal), but the complexity of the coal processing equipment and wear on the turbine blades killed those too.
Quiet, actually. I was at the Museum of Transport in St. Louis this spring and happened into the auto hall just as they fired up the engine on their turbine car. Having spent a lot of time working with industrial gas turbines, I was surprised at how noisy it wasn't - considerably less noise than a piston engine of equivalent horsepower from that era.
Quite a lot of smoke though; they had to open up a garage-sized door for ventilation.
A database is not a bitbucket. Re-building basic database functionality in an external app is not a good idea. Applications, frameworks, languages come and go; data remains forever [1]. Business logic is part of the database. If you find yourself adding more and more "application servers" to get performance than you have a fundamental problem with your architecture (and probably a fundamental misunderstanding of how databases work). While it is not impossible to learn and implement good data management/database development practices using Microsoft tools, such a result is seldom seen in the wild.
sPh
[1] Per Tom Kyte of Oracle, whose first database job at the Department of Agriculture involved working with datasets stretching back to 1790.
Slashdot Mirror
> We had a frequently used query against a sku
> database on style, color, and size.
Love those apparel industry-specific systems and databases. There are reasons why they are designed the way they are (and different from everything else), but they are murderous to work with!
sPh
> Or you could put MySQL on an IBM Power Systems LPAR and use a commercial
> MySQL plug-in [krook.net] to store the data in a DB2 database. Then you can
> get away with maybe a dozen database machines instead of thousands. I have
> to imagine, btw, that Oracle has a similar offering in the works.
Buh.. buh.. buh.. buh... But - that would be like a /mainframe/! Mainframes are archaic and obsolete - everyone knows that! How would you cluster the application servers to a system like that?!? _Everyone_ knows you need application servers!
sPh
> You write the code that actually does the queries as stored procedures
> in the database, then write a DAL that essentially works as a database
> driver. Your code does nothing to the DB other than requesting that it
> execute an SP, and the SPs can be tuned for the specific database server.
True, but that is not writing "database independent code" - it is writing separate versions of the code for each database and building a good UI that can be configured to be compatible with all of the versions. That's exactly what Tom Kyte (of Oracle) recommends as a development strategy, and there is a funny case in _Tales of the Oak Table_ (a book I recommend to everyone involved with databases) where Oracle consultants called to a customer site ended up writing a second version of their customer's code for SQL Server, cleaning up the original version for Oracle, and having both be 100x faster than the original "independent" code with essentially the same total number of source code lines.
> Note that I've explicitly excluded Oracle from that list, as I've never once seen a
> production Oracle database ever reach the performance of... well, any other
> database server, really. I don't doubt that Oracle can be made fast; I just doubt
> that getting the personnel who know how to do that and paying them to do so is
> worth the cost compared to easier to use, less expensive, and faster out of the
> box systems like, oh, DB2 and SQL Server.
We'll have to agree to disagree here. I agree there is some truth in what you say about needing people who actually understand Oracle; if it is installed and used as if it were Access then it doesn't work well. My personal experience however is more with an application running with decent performance on a single Oracle instance being replaced with a "cluster" of SQL Server that starts out with 10 machines (5 databases, 5 of whatever application server Microsoft is pushing this year) and ends up as a cluster(-f***) of 300 or more machines and a constant cry for "more RAM", "more budget", "more servers" - and is never as fast as the system it replaced.
sPh
> - a very clear definition of the problem, hence, the problem shouldn't be
> too big (think a Wordpad sized project)
> - a very thorough knowledge of the technology and its limitations (project
> that works in several web browsers? forget it)
> - almost no variation in deployment and use conditions
>
> Not many projects fall under those categories
And more generally: that is knowledge and wisdom that is typically only obtained by /doing the project/ - hands-on.
sPh
> Exactly, the thing with a SAP rollout (or anything else of this
> magnitude) is that you pass the point of no return quite early
> into the project and then the consultants have you exactly
> where they want you
Here's a thought: consultants are there to do just that: train, guide, and consult (e.g. _assist_ with analyzing). The people doing the implementation should be the organization's managers (not "project managers" - managers) and the employees who will be using the system. Once a project of this type is segregated in the "IS Department" and handed over to "the consultants" it will certainly fail; the former may know what needs to be done but lack the authority to do it (hence the need for managers to be at the core) and the latter's perverse incentives and conflicts of interest are well documented.
sPh
> They would probably need to build an abstraction layer on top of MySQL. :) . This would create the ability to move to
> Something like "FBSQL"
> whatever database system they want.
And get equal performance on all of them. Equally poor, that is.
sPh
> Far too often, vast ignorance, huge ego, and massive pride
> prevent people from considering alternative database solutions
> and their ignorance of the domain allows them to quickly
> become self assured they've picked a winner.
I won't say that those factors don't come into play, because they do. But I think a more fundamental problem is that there has never been a good source of education on how relational databases really work in the corporeal world (as opposed to the theoretical world of CS 350), nor on how to develop scalable performant applications against databases as discussed by Tom Kyte and the Oak Table Group [1]. Instead just about everyone is self-taught, and unfortunately today that means self-taught with Microsoft Access and either MS SQL Server or MySQL - both of which lead to developing bad habits of thought [2] (autoincrementing columns! Yeah! Let's use them as primary keys!).
The somewhere around 2000 everyone decided that "application servers" and "database independent code" were the Wave of the Future(tm), and those without fundamental understanding followed along with the crowd. I have watched more than one performant single-instance Oracle-based application be replaced by a network of 327 servers running a competing RDBMS with the application becoming slower and less stable at ever step, yet it is Inconceivable(tm) to consider going back to the "archaic" design of a single powerful Oracle or DB2 instance with the majority of the business logic integrated into stored procedures. That's fad and fashion working against lack of true understanding, not just inflated ego.
sPh
[1] I'm sure there are other examples of good database design practice out there; those are the two I am most familiar with.
[2] Not that it isn't possible to build good systems with MS SQL Server, because it is possible. It just is rare in my experience.
> And, to add to that, Facebook is insane if they didn't implement
> what is commonly called an "access layer" for abstraction, so
> that the system can be rapidly ported from one RDBMS to another.
"Access layer" aka "database independence". Otherwise known as "absolute death to any hope of performance and scalability". The reason one pays large sums of money for an Oracle, DB2, or even SQL Server implementation and programming is _exactly_ to get the performance and scalability potential and improvements that only come from understanding what your code does in its actual operating environment. And that operating environment and its capabilities are different from product to product; otherwise why would there be more than one? Oracle and SQL Server, for example, use locking philosophies that are 123 degrees apart from one another - how the heck do you write performant code that works against both databases?
sPh
> The number of jetliners with "propellers" is mighty fucking few, though not zero.
The number of airliners with gas turbine engines that turn propellers is in fact quite large.
The bypass fan of a high-bypass turbofan engine is essentially a propeller as well, although ducted.
So that leaves us with the various 707s, DC-8s, and 727s and their military equivalents flying around out there with straight turbojet engines having no fan-push component, which is not all that many in 2011.
sPh
In any case the results of this study should have been blindingly obvious to anyone living in North America during the no-fly week of 9/11 - 9/18.
> . this means one of two things - Oracle are lying (believable)
Oracle are lying about what? There can't be more than a few hundred Itanium users around the world, and Intel has been signaling for years that the product line is dead and won't be replaced. Maybe HP shouldn't have shut down its own CPU development and sold its designs (along with the designs of the DEC Alpha) to Intel, but they did. Now that product line has failed and Oracle is just making an obvious business decision.
sPh
> The probe is expected to perform exploration at L2.
What do they expect to explore at the L2 point? It is just an empty spot in space.
sPh
And any alien reconnaissance satellites parked there would presumably be stealthed.
> Soft drinks used to be sold in glass bottles. It's been too long for me to
> remember whether they were quart (~1 liter) or half-gallon (~2 liter) size,
> but when the switch was made to plastic in the 80s, it was SI all the way.
The glass bottles were 64 oz (and IIRC only Coke used them; I don't recall any Pepsi products in that size). I used to stack the returns at the grocery store, and even empty they were heavy enough to beak your foot if you dropped one.
sPh
There's a technical term for that: core on the floor.
sPh
> 1) You are a true programmer, not just a code hack. You understand how a computer
> actually thinks, how data is stored in memory, how a processor works, etc. You
> understand that languages are just tools to do a job, and all they do is help you describe
> to the computer what you wish it to do. If required you can pick up a new language with
> little trouble because you understand it is all the same process, just different grammar
> and syntax and so on.
I generally agree with that, and throughout the 80s and 90s it was a good strategy to use when fishing (as opposed to screening) for good candidates.
I'd still think hard about someone with solid varied experience. But as a technical manager who does a lot of work with databases and database-based applications I am forced to observe that there is a problem with people who have a lot of experience with Microsoft tools: they are often (not always, but often) damaged when it comes to working with databases. They don't understand database theory, they don't understand the practicalities of implementing performant database apps and managing databases in the real world, and they are absolutely wedded to thought processes (and architectural decisions) that lead to sub-optimal results. It just seems to be something that has come with working in Microsoft environments from about 2000 forward.
Admittedly the same thing often applies to those who have worked with nothing but Java, but the Java-heads are often (not always) re-programmable so to speak.
That's my 0.02 anyway. Could be wrong, but I have seen it again and again.
sPh
> The 50/60 Hz 100/90v division line in Japan dates to the year 1600
> and the battle of Seki-ga-hara [wikipedia.org]
The 50/60 Hz division in Japan dates to the point where Siemens salesmen happened to arrive at one end of the country and General Electric salesmen at the other end. Literally.
sPh
> GPS is a US government system on satellites, and
> the receivers that give a position. Nothing more.
Actually, GPS is also a system that provides an extremely precise timing signal synchronized worldwide. I realize that the availability of such a signal is an essential ingredient of navigation, which is why the US Navy was originally going to call its satellite system "Navstar" (Nav = Navy = Navigation; I hope someday the real story of how the Air Force grabbed control of the project is told). But the precise timing signals, once made available, were and are used for many many things besides navigation. Operating continental electric grids is a good example.
sPh
> It has everything to do with all the other systems using GPS: the thing
> that tracks the location of your important parcel, or keeps the "Next train in
> 5 minutes" indicator accurate, or synchronises the clock on something.
Synchrophasor measurement units, which are being integrated into the power grid for a number of reasons ("smart" and old-fashioned operational as well), are heavily dependent on a GPS timing signal.
sPh
> Well into the 1990s the IBM minicomputer ran OS/2.
System/1, System/34, System/36, and the AS/400 most certainly did not use OS/2 as their operating system(s).
sPh
Ok, that was a particularly egregious typo. Proactive should be "provocative".
sPh
> You know, I thought you were serious until you put this part in.
> Now I'm just laughing... We barely have "unmanned bombers"
> now, much less in the 50's.
It was called Project Pluto, although IIRC there was a different name for the airplane/cruise missile that was to use the Pluto ramjet. After spending some time working on precision targeting systems, the designers realized that the weapon didn't need to hit any specific target; it just needed to fly back and forth over the enemy's terrain at low altitude where the combination of supersonic shock waves, direct radiation, and exhaust fallout would do more than enough damage. The autopilots of the 1950s were more than sufficient for that task.
The project was canceled in part due to concerns about its existence being overly proactive (as stated in the Wikipedia article), but also because the designers finally realized that even in the non-eco 1950s there would be nowhere on the planet that they could test it.
sPh
Um, why don't you send a notarized letter via certified post to your regional IP address manager (e.g. ARIN) describing the details under which you obtained the block and giving up any interest in same? If they need that block back it would at least give them a starting point to work with.
sPh
> There are major practical problems in making small high compression gas turbines
> (among other things, conventional axial or centrifugal flow compressors do not
> scale well to small sizes). The result is very poor fuel economy. Chrysler wasn't
> the only manufacturer to build a gas turbine powered car. Rover built one in the
> 1950's. At best these efforts demonstrated passable, but not exceptional performance
> coupled with VERY high fuel consumption.
Not just automobile-sized turbines either; none of the experiments with turbine-powered locomotives in the 1950s and 60s were very successful; although the Union Pacific's (first deployed in 1948!) had plenty of power for the UP's long routes their fuel economy was so poor that they were only competitive when cheap low-grade fuel was available. When the price of even low-grade Bunker C went up after 1973 it was time for the scrap yard. The Norfolk & Western tried various arrangements of coal-burning turbines (both gasified and powered coal), but the complexity of the coal processing equipment and wear on the turbine blades killed those too.
sPh
>> How noisy were they?
> Extremely
Having just heard a Chrysler Turbine Car in operation this spring, I'll have to respectfully disagree: I was surprised by how quiet it was.
sPh
> How noisy were they?
Quiet, actually. I was at the Museum of Transport in St. Louis this spring and happened into the auto hall just as they fired up the engine on their turbine car. Having spent a lot of time working with industrial gas turbines, I was surprised at how noisy it wasn't - considerably less noise than a piston engine of equivalent horsepower from that era.
Quite a lot of smoke though; they had to open up a garage-sized door for ventilation.
sPh
A database is not a bitbucket. Re-building basic database functionality in an external app is not a good idea. Applications, frameworks, languages come and go; data remains forever [1]. Business logic is part of the database. If you find yourself adding more and more "application servers" to get performance than you have a fundamental problem with your architecture (and probably a fundamental misunderstanding of how databases work). While it is not impossible to learn and implement good data management/database development practices using Microsoft tools, such a result is seldom seen in the wild.
sPh
[1] Per Tom Kyte of Oracle, whose first database job at the Department of Agriculture involved working with datasets stretching back to 1790.