You can perform text-only dumps via bcp (in Sybase ASE and MS SQL). I am sure there is a facility for Oracle that does the same thing.
That aside, not only is the SQL-dump size inefficent, *loading* the data is horribly inefficient (over bin dump) because your indexes must be rebuilt.
Also, you can't (to the best of my knowledge) paralellize the loading in MySQL and PostgreSQL -- meaning you perform 1,000,000 serialized inserts (more or less).
So, the provided mechanisms (bin dump, and CSV-type format) are the best methods to go about doing things. The SQL-based method is a very simplistic, and worst-case solution to backups.
So what's your point? ASCII dumps are HORRIBLY inefficient -- the fact that you *can't* do a bin dump in MySQL/PostgreSQL is horrid -- why support something that provides NO benefit to your application (in this case, Oracle).
If it's not server side compression, the only thing I can think of (and fortunately smarter people than me will think of other things I'm sure) is that he's pre-fetching and caching pages to make the apparent speed faster.
I am guessing this is all he is doing. This would make perfect sense since he has a method of easily controlling the 'speed' -- namely that 7x crashes. I bet that the 7x refers to the depth bound or some other slight variation and the sheer number of things to cache overwhelms the RAM on the PC in question (or his algorithms are NoGood(TM) and there's a leak which is exploited under the higher number of page caches).
Remember, though, that it could be as simple as removing all images as well. It has been a long, long time since I was on dial-up, but I do recall in the early days of 28.8's and such turning off images provided a significant boost.
However in the OLTP application context generally you are not running ad hoc SQL, so views and stored procedures are perfect. To test your query certainly you can type random SQL to the DBMS, but once it is in the application it should be encapsulated in a view or stored procedure.
Views are updatable in most DBMS' -- there is a good series of papers here which discusses the topic more fully.
It seems like he's coming up for a solution to a developer-induced problem, not a problem with DBMS' or DBAs in general.
If you normalize you don't have to worry about null-ability of columns. You don't add and drop columns (usually). Pack those tables behind views and your application doesn't need to change a thing: CREATE VIEW user_info AS
SELECT *
FROM user u
INNER JOIN user_detail ud ON u.username = ud.username
-- etc
Then your app would simply select from that view.
The problem is that developers don't take the time to properly learn relational theory, instead content to know the basic semantics of the SQL language and call themselves 'fluent in SQL'. They know how to create tables in their GUI of choice (or even code it by hand) and are 'database designers'.
Another benefit is stored procedures. Although abused to include procedural logic in the database, they can help keep database logic out of your application and generally help much along the same lines as views: CREATE PROCEDURE get_user_info AS
SELECT *
FROM user u
INNER JOIN user_detail ud ON u.username = ud.username
-- etc
In this case the stored procedure would be called in your application.
I'm just guessing, but what I have seen (and fixed numerous times): 1) Non-use of indexes 2) Improper joins 3) Procedural mindset
Non-use of indexes is easy. Generally they'll run queries with functions on column names, or type-mismatches, etc. (e.g. WHERE colname * 2 = 12000, etc.). Or they'll not request an index when it is necessary.
Improper joins -- joining on non-indexed columns, non-key columns, etc. Or leaving out a join condition and causing a cartesian product.
Procedural logic should not be in the database. Often you'll see a query such as this: SELECT keycol FROM table1 -- loop
SELECT *
FROM table2
WHERE foreign_key = $keycol -- end loop
I think the idea is that you do not *need* to know the name. You save the file as something, and then tie the attributes of 'Personal Finances', 2002, etc. to them. Then if you can't find it again, you open up your file search and check the box labeled 'Personal Finances' and give it the year of 2002.
In 1896 there was a Supreme Court decision called Plessey vs. Ferguson that said separate but equal was constitutional. They didn't say we had to do it -- just that it was fine with the Constitution.
Then in 1954 in Brown vs. the School Board, they said it wasn't constitutional.
Same Constitution, two different meanings? What does this tell us -- namely that the Supreme Court decides what is constitutional or not based upon something other than what the Constitution says and the intent of the Founding Fathers.
Thing is, any fool can tell what the Fathers meant by looking at what they did.
Like the Second Amendment, that says, "A well regulated militia, being necessary to the security of a free state, the right of the people to keep and bear arms, shall not be infringed." They hadn't really figured out commas back then. Everybody argues like crazy about what "militia" meant, and did the Fathers really mean that everybody ought to be able to have guns, and it sounds all solemn and serious.
It ain't.
Back then, everyone and his Aunt Polly had guns, and all their pigs and chickens, and some tadpoles. The Foundling Fathers knew it. So did the Supreme Court. Nobody ever got upset about it. It never occurred to anyone that it was unconstitutional.
If the Fathers had intended something different, they'd have done something different.
As a CTO I would be inclined to deny your request, as it is obviously frivolous and without merit.
Had you included rude, crude, or otherwise obscene representations of VRAPS which were themselves clever and amusing -- so we could refer to it in a more meaningful and appropriate way when it broke -- then it would get rubber-stamped on through the 'process'.
Correct, most "Dvorak is faster than Qwerty" claims are not based on fact. Theoretically, though, your fingers travel less so perhaps you can type faster. I haven't coded Qwerty in a long time so I do not know what speeds are, but I am confident I am no slower.
Most RSI help claims are, of course, anecdotal, but from what I have seen virtually everyone who has switched has seen vast improvements in comfort - that I can't ignore.
A short list of pros and cons are here: http://www.mwbrooks.com/dvorak/procon.html
Note that no claims of speed superiority are made - most speed claims are made by uninformed converts and not by evangelists.
It depends on how often you switch back and forth. If I go a long time (a month) I sit there like an idiot in front of the keyboard hunting and pecking for a while until I can remember.
If you regularly use QUERTY there should be no problem, really. Of course, if your friend uses Windows 2000/XP it is incredibly easy to temporarily change to Dvorak and back. That's what I end up doing if I need to use another computer for any length of time.
The problem comes into play when playing some games - most Quake derivatives (Half-Life, Medal of Honor: Allied Assault, etc.) use hard-coded Querty key layouts, so your keys revert back to Querty. Just something to keep in mind.
You probably won't be any faster, but your fingers *will* travel less. I know I used to have pain in my hands after long coding sessions at work on Querty - after switching to Dvorak I can say I have regained my previous speed (after three months or so) and long coding sessions no longer produce painful fingers!
Of course, you should see your doctor immediately upon RSI-type pain.
Who says compromise is the correct course of action? 2 + 2 is always 4 (nonfunny 'for extremely large/small values of two' quips notwithstanding). The NRA believes their position is 100% correct - compromising would not make sense. Sara Brady et al believe the same thing - that they are 100% correct. This is why nothing meaningful ever happens - each side believes that the other's viewpoints are insane and that 2 + 2 is always 5 (or 3).
747-400ER's max take-off weight is 910,000lb (412,775kg).
A Cessna 150's max take-off weight is 1600lb. So, you'd need 569 such-sized parachutes to hold a fully-laden 747. Who knows if they can be made that large, or strong. Plus the Cessna goes far slower than the 747's.855 mach. Certainly you would not want to deploy them at cruise speed but they would have to deploy at some airspeed which is just enough to keep a big bird like that aloft which is probably many times faster than the Cessna's max speed!
In short, it might be easier and more feasible to give parachutes to all the passangers!
Re:MySQL gains more users thanks to Apple
on
SQL Fundamentals
·
· Score: 2
I'm a CTO and choosing product worth on what a particular vendor says would get me fired. Products stand on their own merit and are evaluated as such.
Re:MySQL gains more users thanks to Apple
on
SQL Fundamentals
·
· Score: 3, Interesting
Having FK support does not make one a Relational DBMS. To those who are 'in the know' Oracle, MS SQL Server, even my beloved:) Sybase ASE etc are SQL-Based DBMS. SQL, to put it mildly, butchers most relational tenets and is not how Codd wanted it to work in the first place (enter IBM and SQL language).
But in the least case MySQL supports relations (tables) so it has, to some degree, a relational background. FK support is required according to Codd, but virtually all DBMS also break some of his other rules as well, so it depends on how deviant a product must be before it is declared non-relational.
The only reason why I could see a RDBMS advantage to image storage is that you can (usually pretty easily) change the block/page size for storage/retrieval to improve fetching of large chunks of data. Usually you can also have finer-grained memory control to ensure they are forced in memory.
That said, I think it is far wiser and much more cost effective to store 'dumb' (non-relational) content like images on the web/app server.
Slashdot Mirror
You can perform text-only dumps via bcp (in Sybase ASE and MS SQL). I am sure there is a facility for Oracle that does the same thing.
That aside, not only is the SQL-dump size inefficent, *loading* the data is horribly inefficient (over bin dump) because your indexes must be rebuilt.
Also, you can't (to the best of my knowledge) paralellize the loading in MySQL and PostgreSQL -- meaning you perform 1,000,000 serialized inserts (more or less).
So, the provided mechanisms (bin dump, and CSV-type format) are the best methods to go about doing things. The SQL-based method is a very simplistic, and worst-case solution to backups.
So what's your point? ASCII dumps are HORRIBLY inefficient -- the fact that you *can't* do a bin dump in MySQL/PostgreSQL is horrid -- why support something that provides NO benefit to your application (in this case, Oracle).
Remember, though, that it could be as simple as removing all images as well. It has been a long, long time since I was on dial-up, but I do recall in the early days of 28.8's and such turning off images provided a significant boost.
However in the OLTP application context generally you are not running ad hoc SQL, so views and stored procedures are perfect. To test your query certainly you can type random SQL to the DBMS, but once it is in the application it should be encapsulated in a view or stored procedure.
Views are updatable in most DBMS' -- there is a good series of papers here which discusses the topic more fully.
If every developer out there had taken 'SQL 101' perhaps we wouldn't be having this conversation in the first place.
It seems like he's coming up for a solution to a developer-induced problem, not a problem with DBMS' or DBAs in general.
If you normalize you don't have to worry about null-ability of columns. You don't add and drop columns (usually). Pack those tables behind views and your application doesn't need to change a thing:
CREATE VIEW user_info AS
SELECT *
FROM user u
INNER JOIN user_detail ud ON u.username = ud.username
-- etc
Then your app would simply select from that view.
The problem is that developers don't take the time to properly learn relational theory, instead content to know the basic semantics of the SQL language and call themselves 'fluent in SQL'. They know how to create tables in their GUI of choice (or even code it by hand) and are 'database designers'.
Another benefit is stored procedures. Although abused to include procedural logic in the database, they can help keep database logic out of your application and generally help much along the same lines as views:
CREATE PROCEDURE get_user_info AS
SELECT *
FROM user u
INNER JOIN user_detail ud ON u.username = ud.username
-- etc
In this case the stored procedure would be called in your application.
I'm just guessing, but what I have seen (and fixed numerous times):
1) Non-use of indexes
2) Improper joins
3) Procedural mindset
Non-use of indexes is easy. Generally they'll run queries with functions on column names, or type-mismatches, etc. (e.g. WHERE colname * 2 = 12000, etc.). Or they'll not request an index when it is necessary.
Improper joins -- joining on non-indexed columns, non-key columns, etc. Or leaving out a join condition and causing a cartesian product.
Procedural logic should not be in the database. Often you'll see a query such as this:
SELECT keycol FROM table1
-- loop
SELECT *
FROM table2
WHERE foreign_key = $keycol
-- end loop
Obviously a JOIN is needed.
I think the idea is that you do not *need* to know the name. You save the file as something, and then tie the attributes of 'Personal Finances', 2002, etc. to them. Then if you can't find it again, you open up your file search and check the box labeled 'Personal Finances' and give it the year of 2002.
Then in 1954 in Brown vs. the School Board, they said it wasn't constitutional.
Same Constitution, two different meanings? What does this tell us -- namely that the Supreme Court decides what is constitutional or not based upon something other than what the Constitution says and the intent of the Founding Fathers.
From FredOnEverything.net:
As a CTO I would be inclined to deny your request, as it is obviously frivolous and without merit.
Had you included rude, crude, or otherwise obscene representations of VRAPS which were themselves clever and amusing -- so we could refer to it in a more meaningful and appropriate way when it broke -- then it would get rubber-stamped on through the 'process'.
SSH-ing into my linux boxen provides no problems since it maps correctly.
m l
Go to google and type in 'Dvorak'. The first link is here:
http://www.mwbrooks.com/dvorak/
There's a "Training" link which points to here:
http://www.mwbrooks.com/dvorak/training.ht
And then finally it points to a great training tool (I used it as well) here:
http://www.karelia.com/abcd/abcd.html
Was that so hard?
All apologies on the repeated misspellings of QWERTY. I subliminally think "QU" and type it as such. :(
No, because I do not use Qwerty (duh). :rolls eyes:
I actually just caught it on my previous post because I was spell checking it in Word.
Correct, most "Dvorak is faster than Qwerty" claims are not based on fact. Theoretically, though, your fingers travel less so perhaps you can type faster. I haven't coded Qwerty in a long time so I do not know what speeds are, but I am confident I am no slower.
Most RSI help claims are, of course, anecdotal, but from what I have seen virtually everyone who has switched has seen vast improvements in comfort - that I can't ignore.
A short list of pros and cons are here:
http://www.mwbrooks.com/dvorak/procon.html
Note that no claims of speed superiority are made - most speed claims are made by uninformed converts and not by evangelists.
It depends on how often you switch back and forth. If I go a long time (a month) I sit there like an idiot in front of the keyboard hunting and pecking for a while until I can remember.
If you regularly use QUERTY there should be no problem, really. Of course, if your friend uses Windows 2000/XP it is incredibly easy to temporarily change to Dvorak and back. That's what I end up doing if I need to use another computer for any length of time.
The problem comes into play when playing some games - most Quake derivatives (Half-Life, Medal of Honor: Allied Assault, etc.) use hard-coded Querty key layouts, so your keys revert back to Querty. Just something to keep in mind.
Also try switching to Dvorak.
You probably won't be any faster, but your fingers *will* travel less. I know I used to have pain in my hands after long coding sessions at work on Querty - after switching to Dvorak I can say I have regained my previous speed (after three months or so) and long coding sessions no longer produce painful fingers!
Of course, you should see your doctor immediately upon RSI-type pain.
Jesus! Can't there be a better way -- because once a man has been kicked, hard, in the balls he ceases te be a man.
Who says compromise is the correct course of action? 2 + 2 is always 4 (nonfunny 'for extremely large/small values of two' quips notwithstanding). The NRA believes their position is 100% correct - compromising would not make sense. Sara Brady et al believe the same thing - that they are 100% correct. This is why nothing meaningful ever happens - each side believes that the other's viewpoints are insane and that 2 + 2 is always 5 (or 3).
747-400ER's max take-off weight is 910,000lb (412,775kg).
.855 mach. Certainly you would not want to deploy them at cruise speed but they would have to deploy at some airspeed which is just enough to keep a big bird like that aloft which is probably many times faster than the Cessna's max speed!
A Cessna 150's max take-off weight is 1600lb. So, you'd need 569 such-sized parachutes to hold a fully-laden 747. Who knows if they can be made that large, or strong. Plus the Cessna goes far slower than the 747's
In short, it might be easier and more feasible to give parachutes to all the passangers!
I'm a CTO and choosing product worth on what a particular vendor says would get me fired. Products stand on their own merit and are evaluated as such.
Having FK support does not make one a Relational DBMS. To those who are 'in the know' Oracle, MS SQL Server, even my beloved :) Sybase ASE etc are SQL-Based DBMS. SQL, to put it mildly, butchers most relational tenets and is not how Codd wanted it to work in the first place (enter IBM and SQL language).
But in the least case MySQL supports relations (tables) so it has, to some degree, a relational background. FK support is required according to Codd, but virtually all DBMS also break some of his other rules as well, so it depends on how deviant a product must be before it is declared non-relational.
The only reason why I could see a RDBMS advantage to image storage is that you can (usually pretty easily) change the block/page size for storage/retrieval to improve fetching of large chunks of data. Usually you can also have finer-grained memory control to ensure they are forced in memory.
That said, I think it is far wiser and much more cost effective to store 'dumb' (non-relational) content like images on the web/app server.
We routinely perform joins on 150+ million row, 10 to 20GB tables. They generally perform very well... Then again we use Sybase ASE 12.5.
Nothing beats MySQL in that environment
Well, besides flat-files you mean?
but that doesn't give them the right to flat-out make up words. "Inapproximability" indeed!