Oracle doesn't care what configuration you run their database on, however they're only willing to support a few. Can you really blame them? Imagine the support calls involved in diagnosing various problems on home-rolled Linux boxes. Ugh.
In case no one else has heard of this "google" service: http://tolkien.slimy.com/tfaq/Istari.html
Re:And getting good grades ...
on
Cheating Made Easy
·
· Score: 3, Insightful
Back in the day college was intended for the privileged. That is how we see a C high school student get into Yale. That is how we see a C Yale student get into Harvard Business School. That is how we see a C Harvard student founding multiple companies. That is how that founder of multiple failed companies gets sweetheart deals on Texas Rangers stock.
And that, dear friends, is how we get a recovering alcoholic, recovering cocaine addict, President.
When you say "back in the day" I am all but certain that you are a privileged, well-educated, white kid.
I regret to inform you that MySQL is actually not faster than Oracle.
MySQL cannot partition data and then either: 1. eliminate partitions and only perform i/o on the relevant one(s), 2. process against all partitions in parallel.
MySQL cannot maintain aggregated images of your data an re-write ad-hoc queries to use the aggregates.
MySQL cannot store metadata that will tell it that postal code implies county, and hence a query that wants data aggregated to the county can use the image of data at postal code granularity. (It is not true that postal code implies county, but you get my point).
MySQL cannot perform an efficient hash-join to save its life (even though a properly designed hash join is mathematically superior in a great many cases) -- and so it falls back on sort-merge regularly.
MySQL cannot re-write NOT IN or NOT EXISTS clauses as merge anti-joins. Neither can it re-write IN or EXISTS clauses as merge outer-joins.
I have to get back to work now, but surely you get the idea.
In the Intelligent Design school of thought so-called scientists look at the world and in essence say "I do not understand, therefor God." We now have a fellow modifying this to read "I do not understand, therfor parallel universes." Lovely.
Someone (Bradford DeLong?) mused to the effect of (my own paraphrasing follows): how much lab equiptment does one need in order to say "I do not understand, therefor God?" Now we know.
I am a topologist by training, so I'm probably biased here.
However, given that, I often find that algorithms are attempts to find a minimal metric. Whenever I try to make a physical process more efficient (packing, routing, etc.) I find that there is an inherent metric that I am working with. This has repeatedly been key to my work, but of course your results may vary.
As a reformed mathmatician myself, I agree with your list and would order it as follows:
1. linear algebra -- Take more than one course that covers linear algebra. Make sure that you really understand that it is not about rows and columns of matrices, but rather that it is about vector spaces and dimensionality. If you understand linear algebra you will use it in all manner of places, if not you will brute force your way through inefficient implementations.
2. topology -- A good understanding of metric spaces will be of enormous use to you in understanding how to optimize your code.
3. discrete math/combinatorics -- This will give you the right background to talk intelligently about whether your code is O(N) or O(N^2), etc.
Now we get into areas that _may_ be useful, depending on the type of coding you do.
4. calculus -- This and numerical analysis allow you to write computational approximations of problems that cannot (easily) be solved analytically. Now go model the weather.
5. number theory -- This is crucial to encoding/decoding data. Audio/video file formats are all instanciations of number theory. In this vein abstract algebra is also essential and finite geometry (all praise Ernie Shult) is terribly useful.
6. abstract algebra -- If you ever plan to write compilers, scripting languages, etc. then abstract algebra will give you the relevant mental framework.
So what's your prefered execution plan for joining a couple of 100,000 row tables, call them A & B? Lets take the ever popular nested loops strategy.
1. We do a full table scan of table A -- 100,000 rows. Cool. 2. For each row we do an index read to find the row id of our target row(s) in B. 3. Now we read the appropriate row(s) of B. 4. Repeat 2 & 3 until finished.
Notice, if you will, that we just did 100,000 read of B's index and at least 100,000 reads of B. Lets say our database does block-reads, with say 8K blocks. Lets say our table has 100 rows per 8K block. Now we just read 100,000 blocks, reading each row an average of 100 time (since we're fetch the whole block to get 1 row).
Or were you advocating sort joins? Those have the same sort & temp space overhead as hash joins and typically don't perform as well -- though implementation is of course central here.
Give your database enough swap space and I think you'll be quite happy with hash joins. They're obviously not appropriate all the time, but when you're joining the preponderance of 2 tables together they really are the best strategy.
Hmm. I don't think you've ever worked with an Oracle database, I really don't. Here are some _important_ performance features in Oracle that MySQL does not have, and may well never have:
- Choose varying parse strategies as your data grows for optimal access
- Choose varying parse strategies based on the histographic distribution of the data
- Re-write NOT EXISTS or NOT IN clauses as merged anti-joins or nested loop anti-joins
- Re-write EXISTS or IN clauses as merged semi-joins or nested loop semi-joins
- create aggregated data tables and have the database transparently maintain the aggregated data as the underlying granular data changes
- Re-write queries against granular data so that they can use aggregate data (when available)
- Give analytic data about the entire result set or partitions of it at the individual row level (i.e. what is the rank of each book by sales within each genre -- with a single query)
- define rules to extrapolate values for missing data elements within a result set
- store an entire table in an index and then treat the index as if it was a table transparently
etc, etc, etc.
When I say that MySQL may well never have these types of feature it is because it is very, very hard to provide them in a robust, fault-tolerant, enterprise database. It is expensive -- and then so is Oracle.
The concept of a kernel isn't all that hard. In math you're commonly looking for mappings (functions) between things that are too complicated to understand and things that aren't. You want to find the relationship between the the complicated one and the intelligible one. Seem reasonable? Ok.
Now in group theory you're looking at very simple algebraic structures, such as: 1. how the integers act under addition, 2. how the positive real numbers act under multiplication, 3. how a book could be put back onto the shelf (i.e backward, upside down, etc). In spite of the fact that in group theory you're only looking at a single operator (addition, multiplication, moving a book around) on a set of elements (integers, positive reals, a book) groups can actually get very complicated. So, in group theory we often want to map a more complicated group to a simpler group.
Now, in each of the above groups there is an "identity" element in the group: zero in addition of integers, 1 in multiplication of positive reals, and with the book the identity corresponds to picking the book up and then putting it back just the way you found it. If we map a complicated group to one of these simpler groups, then the _kernel_ is the set of all elements of the complicated group that map to the identity of the simpler group.
Here's an example.
Complicated group: integers under addition
Simple group: the numbers 0 and 1 with respect to addition modulo 2 (i.e. 0+0=0, 0+1=1, 1+1=0)
Mapping: even numbers map to 0, odd numbers map to 1.
Identity of simple group: 0 (N+0=N, right?)
Kernel of mapping: all even integers (in the complicated group), because all even integers (in the complicated group) map to zero (in the simple group)
And Atiyah has an absolutely wonderful little (very little) book that covers some of the foundations of topology in an accessible, non-rigorous manner. It is the single book that I would hand to anyone who wanted to know what topology was, but didn't want to learn how to read/write proofs.
Ok, I'm back from the bookshelf, and I was entirely mistaken. The book I was refering to above is by Paul Alexandroff and is called _Elementary Concepts of Toplogy_. The book right beside it (also very small) is in fact by Michael Atiyah -- _The Geometry and Physics of Knots_. It is not at all a book for non-mathematicians, but for the record, covers interrelations between knot theory, topological invariants and differential geometry in an astounding breadth for such a slim volume. Wonderful stuff.
Oh my. slashdot wants to know what Category Theory is. Where to start?
Category theory is concerned with the study of mappings between objects of a given type (or category). For example: there are mophisms between "groups" that preserve certain group-theoretic properties, there are likewise morphisms between "topological spaces" that preserve topological properties, etc.
Category theory is the study of how these categories are similar or disimilar, and how mappings between them can illuminate surprising relationships between ostensibly dissimilar areas of mathematics. The point at which category theory really took off was when new relationships between group theory and topology took shape and became "algebraic topology".
I forget the author, but one of the best places to start one's study is the book _Category Theory for the Working Mathematician_.
Yes, and then you'd have eliminated a disturbing proportion of quality reporting that is available on the internet. If a disproportionate number of news stories link back to the ny times or salon, then my friend, that is because they are just that good. The articles are always labeled, and you can simply skip the posts that originate in one of these sites.
Well, if you're designing a model that needs to be implemented across several databases (rather rare) then I'd go with ERwin. It's the tool of choice for consultants who work with many databases -- say data warehouse folk.
On the other hand, if you're working with Oracle you really want to go with Designer. It's not being terribly actively maintained, and will likely be replaced at some later point by JDeveloper, but at this point it is unsurpassed for functionality. You want to generate audit columns (created_by, creation_date, etc) on every table, no problem. You want to create before-insert and before-update triggers on every table to populate the audit columns, no problem. You get the idea. The Oracle database has amazing features that are not (yet?) ANSI standard, so use an Oracle tool to take advantage of them. Rarely does a company invest millions of dollars in a database platform and development effort, only to decide to port it to another database the next year.
I don't know DB2 nearly as well, but it too has phenomenal features (especially for terrabyte databases, though Oracle is catching up nicely) that are not ANSI standard. Again, unless you are one of the reasonably rare folk who need their code to run on any database, don't worry too much about getting "locked" in to the database your company is using and take advantages of the features you're paying for.
And in all honesty, SQL Server is coming along but is still practically a toy in comparison with the two above. You want enterprise features (scalability, availability, clustering, fail-over, etc.) in your database and SQL Server simply does not have them. Postgres is entirely suitable for use as a learning tool, but that's it. Beyond that I haven't seen a database worth installing, in all honesty.
Sigh. In most corners of Europe, and trebly so in France, merely admitting that one is from the U.S. is an open invitation to be told how backward and ignorant one is. While I'm sure that there are plenty of idiotic folk here in the U.S. that would react similarly rudely to one of the french, in the U.S. this is in fact taken as exactly that: rude, retrograde and socially unacceptable behavior. Conversely, in France it is assumed to be the height of sophistication. Therein lies the problem in my esteem.
Those who preach database-neutrality are exactly the same folk who end up giving J2EE a bad name, performance-wise. At a minimum you should isolate the database in a DAO layer that allows you to push logic down to stored procedures in the DB as needed, and within the capabilities and features of the DB in question. A truly performant and scalable design pushes as much data logic into the DB as possible and performs as much business logic as possible in the app server.
For example, if your db of choice handles analytic functions but you perform these calculations in an EJB anyway then you're shooting yourself in the foot. There's a reason that people spend money for DB2 or Oracle, don't waste it needlessly.
It's entirely telling that on slashdot design decisions aren't considered "ideas" (Score:5, Informative). Oh dear. What hope do we have for a decent gui?
Ok, caveat emptor -- I make my living as an Oracle developer. Now given that, here're some features that are used very widely among Oracle customers.
1. The Optimizer -- when your data changes queries against it are parsed differently to give you remarkedly optimal access strategies. This removes well over 90% of the hard work in writing scalable sql.
2. PL/SQL -- this is a sql-based procedural language that makes writing stored procedures very easy and very transparent.
3. SQL -- Oracle implements SQL features that make my life far easier than it would be were I working against _any_ other database. There are analytic functions that return result-set-level data at the level of each individual row. There are scalar queries that transparently perform as simple scalar values, even allowing one to select their contents. For that matter, one can craft a query that contains data for a row as well as additional non-scalar cursors related to it.
4. Objects -- One can create views that store their query results (materialized views) for performance reasons. One can define the hierarchical relationships between different attributes of a table (dimensions) so that the optimizer knows when it can re-write a query and substitute existing aggregate data (materizlized views, above) for more granular data. One can create a queue in the database that supports asynchronous (jms-compliant) messaging in either a push/pull model or a publisher/subscriber model -- these queues can then be associated with one another across different databases to obtain asynchronous messaging between them.
And I'm sure that I'm missing painfully obvious features that are comparable importance. This, quite simply said, is why customers use Oracle. This is why postgres is far, far closer to surplanting Oracle or DB2 than a bit-bucket like mysql.
With respect to "block and row level locking. A select on a 50 million row table shouldn't lock the table." I can only say that a read (i.e. select) should never lock a table in anything approximating a modern database. I think that you meant that a write (insert/update/delete) should not lock rows of a table that are not targets of the statement, yes?
Is this simply another example of the elite being able to buy their way into good grades? In short, it seems that if your parents' wealth can get you into an elite university then you are all but guarenteeing that you will get good grades.
Hell, an anthropology professor at Northwestern University just announced earlier this quarter that he doesn't give out anything other than A's and B's.
Of course I suppose that Bush, et al, would have you believe that I'm engaging in class warfare for simply pointing this out.
As a military man you shouldn't neglect the fact that the battle of the bulge was won because the janitors, cooks, etc. were soldiers who were armed and sent out to take hills. Had those folk all been civilian contractors it's quite doubtful that WW II would have turned the corner then/there.
I don't present this as a final and deciding motivation, and I reccognize that both the military and the world at large has changed enormously in the ensuing 60 years. I simply feel it merits due consideration.
Slashdot Mirror
Calc I, II & III
Differential Equations
Partial Differential Equations
Abstract Algebra
Higher Algebra I (and maybe II, depending on your school)
Topology I (and maybe II)
Differential Geometry
And then I believe you're ready for Tensor Calculus and rudimentary Gauge Theory.
Now just where is it that they cover this in high school?
Scott
Oracle doesn't care what configuration you run their database on, however they're only willing to support a few. Can you really blame them? Imagine the support calls involved in diagnosing various problems on home-rolled Linux boxes. Ugh.
Scott
In case no one else has heard of this "google" service: http://tolkien.slimy.com/tfaq/Istari.html
Back in the day college was intended for the privileged. That is how we see a C high school student get into Yale. That is how we see a C Yale student get into Harvard Business School. That is how we see a C Harvard student founding multiple companies. That is how that founder of multiple failed companies gets sweetheart deals on Texas Rangers stock.
And that, dear friends, is how we get a recovering alcoholic, recovering cocaine addict, President.
When you say "back in the day" I am all but certain that you are a privileged, well-educated, white kid.
Sigh.
I regret to inform you that MySQL is actually not faster than Oracle.
MySQL cannot partition data and then either: 1. eliminate partitions and only perform i/o on the relevant one(s), 2. process against all partitions in parallel.
MySQL cannot maintain aggregated images of your data an re-write ad-hoc queries to use the aggregates.
MySQL cannot store metadata that will tell it that postal code implies county, and hence a query that wants data aggregated to the county can use the image of data at postal code granularity. (It is not true that postal code implies county, but you get my point).
MySQL cannot perform an efficient hash-join to save its life (even though a properly designed hash join is mathematically superior in a great many cases) -- and so it falls back on sort-merge regularly.
MySQL cannot re-write NOT IN or NOT EXISTS clauses as merge anti-joins. Neither can it re-write IN or EXISTS clauses as merge outer-joins.
I have to get back to work now, but surely you get the idea.
Cheers,
Scott
In the Intelligent Design school of thought so-called scientists look at the world and in essence say "I do not understand, therefor God." We now have a fellow modifying this to read "I do not understand, therfor parallel universes." Lovely.
Someone (Bradford DeLong?) mused to the effect of (my own paraphrasing follows): how much lab equiptment does one need in order to say "I do not understand, therefor God?" Now we know.
Cheers,
Scott
I am a topologist by training, so I'm probably biased here.
However, given that, I often find that algorithms are attempts to find a minimal metric. Whenever I try to make a physical process more efficient (packing, routing, etc.) I find that there is an inherent metric that I am working with. This has repeatedly been key to my work, but of course your results may vary.
Cheers,
Scott
As a reformed mathmatician myself, I agree with your list and would order it as follows:
1. linear algebra -- Take more than one course that covers linear algebra. Make sure that you really understand that it is not about rows and columns of matrices, but rather that it is about vector spaces and dimensionality. If you understand linear algebra you will use it in all manner of places, if not you will brute force your way through inefficient implementations.
2. topology -- A good understanding of metric spaces will be of enormous use to you in understanding how to optimize your code.
3. discrete math/combinatorics -- This will give you the right background to talk intelligently about whether your code is O(N) or O(N^2), etc.
Now we get into areas that _may_ be useful, depending on the type of coding you do.
4. calculus -- This and numerical analysis allow you to write computational approximations of problems that cannot (easily) be solved analytically. Now go model the weather.
5. number theory -- This is crucial to encoding/decoding data. Audio/video file formats are all instanciations of number theory. In this vein abstract algebra is also essential and finite geometry (all praise Ernie Shult) is terribly useful.
6. abstract algebra -- If you ever plan to write compilers, scripting languages, etc. then abstract algebra will give you the relevant mental framework.
Cheers,
Scott
So what's your prefered execution plan for joining a couple of 100,000 row tables, call them A & B? Lets take the ever popular nested loops strategy.
1. We do a full table scan of table A -- 100,000 rows. Cool.
2. For each row we do an index read to find the row id of our target row(s) in B.
3. Now we read the appropriate row(s) of B.
4. Repeat 2 & 3 until finished.
Notice, if you will, that we just did 100,000 read of B's index and at least 100,000 reads of B. Lets say our database does block-reads, with say 8K blocks. Lets say our table has 100 rows per 8K block. Now we just read 100,000 blocks, reading each row an average of 100 time (since we're fetch the whole block to get 1 row).
Or were you advocating sort joins? Those have the same sort & temp space overhead as hash joins and typically don't perform as well -- though implementation is of course central here.
Give your database enough swap space and I think you'll be quite happy with hash joins. They're obviously not appropriate all the time, but when you're joining the preponderance of 2 tables together they really are the best strategy.
Scott
Hmm. I don't think you've ever worked with an Oracle database, I really don't. Here are some _important_ performance features in Oracle that MySQL does not have, and may well never have:
- Choose varying parse strategies as your data grows for optimal access
- Choose varying parse strategies based on the histographic distribution of the data
- Re-write NOT EXISTS or NOT IN clauses as merged anti-joins or nested loop anti-joins
- Re-write EXISTS or IN clauses as merged semi-joins or nested loop semi-joins
- create aggregated data tables and have the database transparently maintain the aggregated data as the underlying granular data changes
- Re-write queries against granular data so that they can use aggregate data (when available)
- Give analytic data about the entire result set or partitions of it at the individual row level (i.e. what is the rank of each book by sales within each genre -- with a single query)
- define rules to extrapolate values for missing data elements within a result set
- store an entire table in an index and then treat the index as if it was a table transparently
etc, etc, etc.
When I say that MySQL may well never have these types of feature it is because it is very, very hard to provide them in a robust, fault-tolerant, enterprise database. It is expensive -- and then so is Oracle.
Cheers,
Scott
The concept of a kernel isn't all that hard. In math you're commonly looking for mappings (functions) between things that are too complicated to understand and things that aren't. You want to find the relationship between the the complicated one and the intelligible one. Seem reasonable? Ok.
Now in group theory you're looking at very simple algebraic structures, such as: 1. how the integers act under addition, 2. how the positive real numbers act under multiplication, 3. how a book could be put back onto the shelf (i.e backward, upside down, etc). In spite of the fact that in group theory you're only looking at a single operator (addition, multiplication, moving a book around) on a set of elements (integers, positive reals, a book) groups can actually get very complicated. So, in group theory we often want to map a more complicated group to a simpler group.
Now, in each of the above groups there is an "identity" element in the group: zero in addition of integers, 1 in multiplication of positive reals, and with the book the identity corresponds to picking the book up and then putting it back just the way you found it. If we map a complicated group to one of these simpler groups, then the _kernel_ is the set of all elements of the complicated group that map to the identity of the simpler group.
Here's an example.
Complicated group: integers under addition
Simple group: the numbers 0 and 1 with respect to addition modulo 2 (i.e. 0+0=0, 0+1=1, 1+1=0)
Mapping: even numbers map to 0, odd numbers map to 1.
Identity of simple group: 0 (N+0=N, right?)
Kernel of mapping: all even integers (in the complicated group), because all even integers (in the complicated group) map to zero (in the simple group)
That wasn't so bad, now was it?
Scott
And Atiyah has an absolutely wonderful little (very little) book that covers some of the foundations of topology in an accessible, non-rigorous manner. It is the single book that I would hand to anyone who wanted to know what topology was, but didn't want to learn how to read/write proofs.
Ok, I'm back from the bookshelf, and I was entirely mistaken. The book I was refering to above is by Paul Alexandroff and is called _Elementary Concepts of Toplogy_. The book right beside it (also very small) is in fact by Michael Atiyah -- _The Geometry and Physics of Knots_. It is not at all a book for non-mathematicians, but for the record, covers interrelations between knot theory, topological invariants and differential geometry in an astounding breadth for such a slim volume. Wonderful stuff.
Scott
Oh my. slashdot wants to know what Category Theory is. Where to start?
Category theory is concerned with the study of mappings between objects of a given type (or category). For example: there are mophisms between "groups" that preserve certain group-theoretic properties, there are likewise morphisms between "topological spaces" that preserve topological properties, etc.
Category theory is the study of how these categories are similar or disimilar, and how mappings between them can illuminate surprising relationships between ostensibly dissimilar areas of mathematics. The point at which category theory really took off was when new relationships between group theory and topology took shape and became "algebraic topology".
I forget the author, but one of the best places to start one's study is the book _Category Theory for the Working Mathematician_.
Cheers,
Scott
Simple, no?
Scott
Well, if you're designing a model that needs to be implemented across several databases (rather rare) then I'd go with ERwin. It's the tool of choice for consultants who work with many databases -- say data warehouse folk.
On the other hand, if you're working with Oracle you really want to go with Designer. It's not being terribly actively maintained, and will likely be replaced at some later point by JDeveloper, but at this point it is unsurpassed for functionality. You want to generate audit columns (created_by, creation_date, etc) on every table, no problem. You want to create before-insert and before-update triggers on every table to populate the audit columns, no problem. You get the idea. The Oracle database has amazing features that are not (yet?) ANSI standard, so use an Oracle tool to take advantage of them. Rarely does a company invest millions of dollars in a database platform and development effort, only to decide to port it to another database the next year.
I don't know DB2 nearly as well, but it too has phenomenal features (especially for terrabyte databases, though Oracle is catching up nicely) that are not ANSI standard. Again, unless you are one of the reasonably rare folk who need their code to run on any database, don't worry too much about getting "locked" in to the database your company is using and take advantages of the features you're paying for.
And in all honesty, SQL Server is coming along but is still practically a toy in comparison with the two above. You want enterprise features (scalability, availability, clustering, fail-over, etc.) in your database and SQL Server simply does not have them. Postgres is entirely suitable for use as a learning tool, but that's it. Beyond that I haven't seen a database worth installing, in all honesty.
Good luck,
Scott
I'd die happy just to hear Patti Smith singing "Jimi Hendrix is a Rock'n Roll Cracker, Jesus Christ and gramma too."
Scott
Mmm, a condescending European. How novel.
Sigh. In most corners of Europe, and trebly so in France, merely admitting that one is from the U.S. is an open invitation to be told how backward and ignorant one is. While I'm sure that there are plenty of idiotic folk here in the U.S. that would react similarly rudely to one of the french, in the U.S. this is in fact taken as exactly that: rude, retrograde and socially unacceptable behavior. Conversely, in France it is assumed to be the height of sophistication. Therein lies the problem in my esteem.
Scott
- Who are you?
The new Number Two.
- Whose side are you on?
That would be telling.
Those who preach database-neutrality are exactly the same folk who end up giving J2EE a bad name, performance-wise. At a minimum you should isolate the database in a DAO layer that allows you to push logic down to stored procedures in the DB as needed, and within the capabilities and features of the DB in question. A truly performant and scalable design pushes as much data logic into the DB as possible and performs as much business logic as possible in the app server.
For example, if your db of choice handles analytic functions but you perform these calculations in an EJB anyway then you're shooting yourself in the foot. There's a reason that people spend money for DB2 or Oracle, don't waste it needlessly.
Cheers,
Scott
It's entirely telling that on slashdot design decisions aren't considered "ideas" (Score:5, Informative). Oh dear. What hope do we have for a decent gui?
Ok, caveat emptor -- I make my living as an Oracle developer. Now given that, here're some features that are used very widely among Oracle customers.
1. The Optimizer -- when your data changes queries against it are parsed differently to give you remarkedly optimal access strategies. This removes well over 90% of the hard work in writing scalable sql.
2. PL/SQL -- this is a sql-based procedural language that makes writing stored procedures very easy and very transparent.
3. SQL -- Oracle implements SQL features that make my life far easier than it would be were I working against _any_ other database. There are analytic functions that return result-set-level data at the level of each individual row. There are scalar queries that transparently perform as simple scalar values, even allowing one to select their contents. For that matter, one can craft a query that contains data for a row as well as additional non-scalar cursors related to it.
4. Objects -- One can create views that store their query results (materialized views) for performance reasons. One can define the hierarchical relationships between different attributes of a table (dimensions) so that the optimizer knows when it can re-write a query and substitute existing aggregate data (materizlized views, above) for more granular data. One can create a queue in the database that supports asynchronous (jms-compliant) messaging in either a push/pull model or a publisher/subscriber model -- these queues can then be associated with one another across different databases to obtain asynchronous messaging between them.
And I'm sure that I'm missing painfully obvious features that are comparable importance. This, quite simply said, is why customers use Oracle. This is why postgres is far, far closer to surplanting Oracle or DB2 than a bit-bucket like mysql.
Cheers,
Scott
With respect to "block and row level locking. A select on a 50 million row table shouldn't lock the table." I can only say that a read (i.e. select) should never lock a table in anything approximating a modern database. I think that you meant that a write (insert/update/delete) should not lock rows of a table that are not targets of the statement, yes?
Scott
Is this simply another example of the elite being able to buy their way into good grades? In short, it seems that if your parents' wealth can get you into an elite university then you are all but guarenteeing that you will get good grades.
Hell, an anthropology professor at Northwestern University just announced earlier this quarter that he doesn't give out anything other than A's and B's.
Of course I suppose that Bush, et al, would have you believe that I'm engaging in class warfare for simply pointing this out.
Scott
As a military man you shouldn't neglect the fact that the battle of the bulge was won because the janitors, cooks, etc. were soldiers who were armed and sent out to take hills. Had those folk all been civilian contractors it's quite doubtful that WW II would have turned the corner then/there.
I don't present this as a final and deciding motivation, and I reccognize that both the military and the world at large has changed enormously in the ensuing 60 years. I simply feel it merits due consideration.
Scott