2 ms·
It's really simple. I did it back in 2001, when I did it I used XML and a stored proc to read the XML and write directly to a cursor. It probably takes an hour
by fleitz 15y ago
It's really simple. I did it back in 2001, when I did it I used XML and a stored proc to read the XML and write directly to a cursor. It probably takes an hour to do it the first time and about 15 to 20 minutes once you're used to the idea of it. (on SQL Server 2000)
With something like SQL Server 2005 it's super simple (< 5 mins) you can basically write an XML file as a stream to your DB server and it eats it and writes directly to the table. (SQL Server supports transforming XML into a table using XPath). You can basically treat the connection like a filehandle and dump XML directly to the stream. Just make sure you open/close the connection often enough not to cause the lock optimizer to grab a table lock. (Or just grab a table lock if you really want it to scream)
All you need to ensure is that you don't hold the steam open too long. If you don't mind a little logic in your DB server you can even consume complex object graphs. If you go the XML route you can max the CPU on your DB server which is generally a bad thing for the most part on modern systems it won't matter unless your DB server has 200+ disks.
You can use this type of system to stream 200 or 300 MB worth of data to your server in a few seconds. This assumes your DB server isn't a piece of crap. (If it can't keep up with a gig ethernet card on random IO or is virtualized it's most likely a piece of crap).
The more generic version is to take advantage of the INSERT syntax and use multiples sets of values.
eg.
INSERT INTO foo (id) VALUES (1),(2),(3);
instead of
INSERT INTO foo (id) VALUES (1);
INSERT INTO foo (id) VALUES (2);
INSERT INTO foo (id) VALUES (3);
Now because MySQL is one of the most retarded (I mean that in the literal sense of the word) databases in the world it doesn't support prepared statements so you get huge overhead when you issue SQL to it, compared to a prepared statement. Also, make sure you explicitly start a transaction before you issue a bunch of inserts, else each statement becomes its own transaction.
Also on the readside to increase performance use something like MARS and issue multiple SELECT statements.
eg.
SELECT * from parent where id = 5;
SELECT * from child where parent_id = 5;
If you have to do more than a few levels consider a SHAPE query. Or use map reduce and 'fold' your join back into something sane.
- dkoch 15y agoMySQL has had server-side prepared statements since 5.0.
- SomeOtherGuy 15y agoYou forgot the asterisk and the list of limitations, bugs and "features" that are like bugs in that they cause problems, only were done intentionally.