DB konverzio ket kulonbozo adatszerkezet kozott

Adatbázis: SQL, XML DB

Sziasztok!

Adott egy nagyon szar db, a feladataink koze tartozik, hogy azt ujratervezzuk. Ez megtortent, most irni kellene egy scriptet, amivel at tudjuk huzni egyik db-bol a masikba az adatokat.

Arra jutottam, hogy az lenne a legegyszerubb/leghatekonyabb, ha modulonkent irnank egy-egy stored procedure-t, amiben egy kurzorral vegigszaladnank az erintett tablakon es beraknank az adatokat a sajatjainkban.

A problema az, hogy rengeteg oszlopunk van, es Google csak abban tudott segiteni, hogy "FETCH column INTO variable"-vel egyesevel dolgozzam fel a dolgokat, majd azokat inserteljem be. Tud esetleg valaki olyan megoldast, amivel ezt meg tudnam kerulni es egy tablaba rakjak bele mindig egy sort, amit aztan fel tudok dolgozni INSERT INTO `users` (`username`, ...) VALUES (`original`.`username`, ...); modszerrel?

  • 1547 megtekintés

( andrej_ v | 2011. 02. 22., k – 16:49 )

INSERT INTO table SELECT.... ha egyezik az oszlopszám. Ha nem egyezik, akkor sem sokkal bonyolultabb. :)

Ha összetetteb variálások kellenek, akkor mindenképp egy perl, php stb scriptet javaslok a bűvészkedésre.

( Formind | 2011. 02. 22., k – 17:20 )

insert into new_user.new_table
select t1.colkell1, t1.colkell2, t2.colkell33
from
old_user.old_table1 t1,
old_user.old_table2 t2,
...
where t1.colx = t2.colx
a kapcsolatokat, céloszlopokat te tudod.
szerk.:
kurzor nélkül.

ok, leesett, ezt igy siman.

a gond ezzel az, hogy van, ahova statikusan kell berakni adatot, tehat values is kellene, meg van, hogy a regiben egy dolog eldonti, hogy melyik lehetoseg, az ujban viszont tobbet lehet megadni neki, szoval egy fieldtol fuggoen kell valamelyik oszlopban a true-t becheckelni. Azt is meg lehet igy csinalni?

Ez eddig ok, csak kellene olyan is bele, hogy valami statikus, bar ezt meg tudom oldani azzal is, hogy kihagyom a valuesbol, aztan utana vegigupdatelem a tablat where feltetel nelkul.

A masik gond az, hogy van olyan, hogy user type, ami a regiben egy varchar volt, es bele volt irva, hogy milyen tipusu a user. Az ujban viszont azt kertek, hogy egy usernek tobb tipusa is lehessen, szoval most a tipusok fel vannak sorolva kulon TINYINT(1) oszlopokban. Erre kellene valami otlet, valamint arra, hogy ha legyartom a user_profilet, utana bele kellene rakni a usernek a profile_id oszlopaba a linkelt profilet. Kurzorral ez egy LAST_INSERT_ID() volt, most viszont nem tudom, hogy lehetne, ha egymas utan fut le a ket query a ket kulon tablara.

Eddig ennyi jutott eszembe, valakinek otlet? :)

csak kellene olyan is bele, hogy valami statikus,

A
select col1, 'string', col2 from tab
megvan?

Az ujban viszont azt kertek, hogy egy usernek tobb tipusa is lehessen, szoval most a tipusok fel vannak sorolva kulon TINYINT(1) oszlopokban.

http://dev.mysql.com/doc/refman/5.1/en/control-flow-functions.html#func…

Erre kellene valami otlet, valamint arra, hogy ha legyartom a user_profilet, utana bele kellene rakni a usernek a profile_id oszlopaba a linkelt profilet.
most viszont nem tudom, hogy lehetne, ha egymas utan fut le a ket query a ket kulon tablara.

Először legyártod a profile táblát, mégpedig az eredeti adatbázisban szereplő ID-ket használva (azaz változatlan ID-kkel kell berakni az új adatbázisba).
Innen szerintem megoldod magadtól is :)

Mondjuk szerintem többet szivatod magad a live migrationnal, mintha készítenél valami scriptet/programot, ami elfogadható időn belül legenerálja a régi adatbázisból az újat vagy akár SQL script formájában.

Vagy ha tényleg ennyire élet-halál kérdése a 24/7/365 órás működés (gondolom 1-2 óra azért belefér), akkor szerintem van arra is pénz, hogy átmigráljátok és a régi rendszerbe belefejlesszétek, hogy egy migrációs rétegen keresztül kommunikáljon mindkét adatbázisba vagy valami egyéb megoldást találjatok ki rá.

----------------
Lvl86 Troll

nem live migration kell, az kell, hogy egy ejszakara leall a site egy maintanance mode-al, es akkor kicsereljuk az egesz site-ot ugy, ahogy van. Adatokat nem igazan menthetjuk le elotte, mert ha megy a site, akkor kozben ugy valtoznak. A migracios reteg pedig kurva nagy szopas lenne, foleg, hogy a regi site kodjahoz nem ferunk hozza, mert azt mas ceg irta.

Adatokat nem igazan menthetjuk le elotte, mert ha megy a site, akkor kozben ugy valtoznak.

De. Van olyan, hogy először menet közben átmásoltok mindent, majd leállás alatt már csak azt, ami idő közben megváltozott. Lehet többször iterálni a leállás előtt, hogy minél rövidebb legyen a leállási idő.

Ezt nem tudom(oracle elvileg tudja, snapshot).

Viszont ha lehet, akkor válaszd kétfelé:
nem változó adat, változó adat.
Van olyan, hogy ROWID? Erre elég gyors
selectet lehetne írni, és a különbség gondolom nem lenne jelentős.
Az is megoldás, hogy táblánként eltárolod az utsó ROWID-et és
akár dinamikusan, akár insert into new_table select from old_table where not exists formával áttöltöd
a változást(tablanev, last_rowid lennének az oszlopok).

Oracle is, mysql is tud olyat, hogy egy oszlopba timestampet tesz automatikusan, ha módosítod.

http://dev.mysql.com/doc/refman/5.0/en/timestamp.html

In a CREATE TABLE statement, the first TIMESTAMP column can be declared in any of the following ways:
With both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP clauses, the column has the current timestamp for its default value, and is automatically updated.

( csizmadia_zoltan v | 2011. 02. 22., k – 17:00 )

Szervusz !

a forrás adatbázis-kezelő és a cél adatbázis- kezelő nincs megnevezve.

PHP + MySQL-ben listázás és kreáláshoz szükséges script képernyőre kiírása:
<?php
# adattábla listázó

$host = "127.0.0.1";
$juzer = "juzer";
$jelszo="jelszo";
$kapcsolat = mysql_connect($host, $juzer, $jelszo);
mysql_select_db("information_schema", $kapcsolat);

$sql = "SELECT TABLE_NAME FROM TABLES WHERE TABLE_SCHEMA=adatbazis_nev' ";
# print $sql."
";
$eredmeny = mysql_query($sql, $kapcsolat) or die(mysql_error());

# print "

";
while ($munkatomb = mysql_fetch_array($eredmeny)) {

print "CREATE TABLE".$munkatomb['TABLE_NAME']." (";
$kerdes = "SELECT COLUMN_NAME, COLUMN_TYPE, COLUMN_KEY, EXTRA FROM COLUMNS WHERE TABLE_SCHEMA='adatbazis_nev' AND TABLE_NAME='".$munkatomb['TABLE_NAME']."' " ;
# print $kerdes."
";
$rezult = mysql_query($kerdes, $kapcsolat) or die(mysql_error());

while ($rezulttomb = mysql_fetch_array($rezult)) {
print "".$rezulttomb['COLUMN_NAME']." ".$rezulttomb['COLUMN_TYPE']." ".$rezulttomb['COLUMN_KEY']." ".$rezulttomb['EXTRA'].", ";
}
print " );

";
} /* vhile */
print "

";

?>

Csinálhatod úgy, ha bizonyos táblák azonosak, akkor azokat egy az egybe átmented, a többit meg kiexportálod mondjuk csv fájlba és azt eteted meg az új adatbázissal, de szvsz ilyen méreteknél inkább, mint feljebb is javasolták a php script a legegyszerűbb/leggyorsabb.

igen, valahogy mindig elfelejtek kozolni par relevans infot, ezt mar megfigyeltem :D egyebkent igen, egy ejszaka alatt kellene atallnunk rohadtgyorsan az egesz site-al. A db ugy 9 GB, szoval nem vagyok biztos benne, hogy ez lehetseges. Majd meglatjuk, milyen vasuk van :) De a kurzoros megoldas is ugrott, pedig azt mar sikerult megoldanom, csak tul lassu volt :D

( hal | 2011. 02. 22., k – 22:09 )

"feladataink koze tartozik, hogy azt ujratervezzuk. Ez megtortent, most irni kellene egy scriptet"

Gondolom a legcélszerűbb az lenne, hogy az csinálja a migrálást aki az új adatbázist tervezte.