Adatbázis: SQL, XML DB

Üdv!

PostgreSQL táblában szeretnék sorokat frissíteni CSV fájlból. Ezt a megoldást olvastam több helyen, ill. a PgSQL doksiban sem láttam jobb megoldást.
Más lehetőség lehet még?

-- átmeneti tábla létrehozás
CREATE TEMP TABLE tmp_tbl (id int, val1 text);


-- átmeneti tábla feltöltése csv fájlból
COPY tmp_tbl FROM '/path/to/file.csv' delimiter ';' ; -- (FORMAT csv);

-- tbl tábla frissítése az átmeneti táblából
UPDATE tbl
SET val1 = tmp_tbl.val1
FROM tmp_tbl
WHERE tbl.id = tmp_tbl.id;

-- átmeneti tábla eldobása
DROP TABLE tmp_tbl;

Sziasztok!

Valamilyen űrlapkészítő programot keresek ami könnyen használható és később mssql-el is használható.
Viszont első körben annyit tudjon, hogy online meg lehessen jeleníteni és a kitöltött űrlapból lehessen pdf-et generálni.

Légyszíves aki használ ilyet és van benne tapasztalta ossza meg velem.
Köszönöm!

A probléma a következő. Van egy tábla amiben nevek vannak. Ha lekérdezést indítok:

A nev táblában az alábbi adatok vannak:

Andrea
Béla
Áron
Berta

SELECT nev FROM table ORDER BY nev

Akkor a rendezés nem lesz jó. Az eredmény az alábbi: Andrea, Berta, Béla, Áron

Hogy lehetne rendes UTF-8-as rendezést csinálni?

Ha a MYSQL tudja ezt akkor talán átállok arra...

Üdv!
Egy PgSQL adatbázisban van egy master-detail táblakapcsolat, pl.:
master (mid,name,typeid,desc...)
detail (mid,detail,val...)

Az mid mező egy serial (autoincrement) és ez a kulcsmező a master táblában, amivel a detail táblához kapcsolódik.

Ez alapján próbálom azt megoldani (pgsql script), hogy mindkét táblában egy rekordot szeretnék lemásolni (adott feltétellel, pl. mid=25), de az mid mezőt fel kellene használnom a detail táblában:

// eddig működik:
INSERT INTO master(name,typeid,desc)
(SELECT name,typeid,desc FROM master WHERE mid=25)
RETURNING mid;


//
// INSERT INTO detail(mid,detail,val)... ???
//

A "RETURNING mid" értékét el kellene tárolni, hogy felhasználjam az INSERT INTO detail... részben.

Hogyan lehet ezt megtenni?

Sziasztok,

Piackutatást végeznék. Adatok migrálásával kapcsolatban a következő dolgok érdekelnek, leginkább Linux alapú rendszereken:
1. Milyen disztribúciót használtok?
2. Milyen adatbáziskezelő rendszert használtok (több is megadható)?
3. Milyen eszközt használtok adatbázisok migrálására?
4. Migrálás közben használtok/használnátok transzformációkat?
5. Mik azok a kritériumok, amelyek teljesülése esetén lecserélnétek meglévő adatmigrációs eszközötöket?
6. Milyen migrálásokat végeztek? (Ad-hoc, időzített betöltés)
7. Adatmigráció milyensége (ETL folyamatok, backup készítés, OLTP adatbázisok szinkronizálása).

RDBMS built-in feature-ök nem játszanak (pl replikáció), illetve a dump alapú mentések sem, jellemzően tábla adatok migrációjáról van szó.

A válaszokat előre is köszönöm. Ha felmerülne még kérdés, akkor azt update-ként veszem fel.

Sziasztok.

Azt hiszem egy kicsit már belerágtam magam a dinamikus honlapok localhoston történő manipulálásába, de nem annyira, hogy tudjam is, mit művelek. Viszont ha kinyitok egy könyvet a témában, már tudom, mit keressek és hogyan.

A kérdésem rövid, de azt hiszem összetett is.

Egy ubuntura sikerült a LAMP-ot felraknom eddig, slackware-re nem.
Lila gőzöm sincs, hogy egy mysql adatbázis (melyből saját php kóddal már olvasni is tudtam) fizikailag hol is van.
Azért érdekelne ez, mert néha bizony "leáll" a böngészőben a phpmyadmin valami eszement üzenettel, melyet még nem értek és aggódom, hogy ha építek egy adatbázist valami CMS-sel, akkor egy végzetes halálnál nem tudom onnan kinyerni.

Szóval a teljesen kezdő kérdés:
meg tudom-e csinálni azt, hogy egyik distribben a nem tudom hova pakolódó adatbázist átrakom egy stabilabbnak vélt másik distribre? (Nos, ilyeneket nem találtam eddig könyvekben)

Az is érdekelne, hogy egy LAMP mikből, milyen csomagokból áll eltérő distribeknél. Mert ahogy tapasztaltam, slackware-ben még az apache csomagneve is más.(Vagy tévedek?)

Üdv!

Érdeklődöm, hogy milyen finomhangolást szoktatok PgSQL szerveren beállítani.
Ezt olvasgatom: http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html

A környezet egyébként konkrétan egy kisebb adatbázisszerver:
-----------------------------------------
RAM: 16GB
Disks: 2*1TB raid1 (szoftveres) SATA HDD
CPU: intel Corei5
OS: CentOS7 x64
-----------------------------------------

Egyelőre az alapértékekből a doksi szerinti "shared_buffer" paramétert állítottam 32MB-ról 512MB-ra. Bár azt írja, hogy a fizikai RAM 25%-a is beállítható (ha van memóriád, pl. 1GB+).

Nagy terhelése nem lesz a rendszernek, max. 3-4 user használja majd egyidőben.
Más paraméterrel szoktatok még játszadozni?

Sziasztok,

Az elmúlt 3 napban egy 9.4.5-ben bejött hibát vadásztunk, amely bizonyos táblastruktúra, és updatelhető view kombinációjával jön elő. A hiba
mind windows-os, mind linux-os buildben benne van, sőt, a 9.5-ösben is reprodukálni tudtuk.

Itt a hiba leírása:

http://postgresql.nabble.com/BUG-13781-quot-unrecognized-node-type-quot…

Minimál teszteset elérhető, de esélyes, hogy zero-day exploit-ot lehet belőle csinálni, tehát amíg nincs javítás, nem lesz publikálva.

Tehát, ha PostgreSQL-t használó kódot fejlesztetek vagy üzemeltettek, akkor egyelőre maradjatok 9.4.4-en, ha pedig updateltek, akkor
érdemes lenne vagy visszamenni a régire (9.4.4). Annyit tudok még mondani, hogy ha forráskódból fordítottátok, akkor érdemes bekapcsolni
a --enable-cassert -et, mert ez legalább a crash-től megvéd. (Ubuntu server-en bizony kőkeményen crash-el)

Sziasztok!

Van egy (szerintem) nagyon jó feladatom számotokra. Adott 7 szerver, teljesen más-más adatbázisokkal. Valahol csak 2 DB van, van ahol 22. Van amelyik 10 MB, van ami 3 GB. Ki lett találva, hogy időspórolás és HW erőforrások megfelelő elosztása érdekében legyenek csak havonta teljes backup-ok, naponta viszont legyen differenciális backup. Na, én meg rábólintottam, hogy ez jó ötlet... csak épp nem tudtam, hogy a MySQL alapból nem tud ilyet és csak mókolt szkripteket találtam a Google segítségével.
A backup úgy készül jelenleg, hogy van egy Backup szerver aki X időközönként be SSH-zik a kliensekre, csinál egy SQL dumpot kompletten, csinál egy tar-gz fájlt a /var/www-ről majd ezt a 2 fájlt az rsnapshot szépen átmásolja a szerverre a megfelelő helyre. Ez addig szépen és jól ment míg el nem értük a gigás méreteket. :)

Kérdés: Ti hogyan csinálnátok minden adatbázisról különbözeti mentéseket? És, ha lehet nem növekvőt, hanem különbözetit. Szerintem az biztonságosabb, de cáfoljatok meg kérlek, ha nem. :)

A rendszerek amúgy CentOS 6-7 alapúak.

Szerintetek mennyire veszteséges egy mysql replikációt nem a mysqld saját beépített módján "etetni", hanem `mysqlbinlog relaylog.000001` -szerű parancsok kimenetét közvetlenül beletolni?

Az IO Thread mehet nyugodtan, az lehúzza a binlogokat,
viszont (mysqld verzió különbség miatt) az SQL Thread hibára szokott futni, ezért egysmás statement-et át kéne írni amit a SLAVE végrehajt.

Így arra gondoltam, hogy programatikusan átiratom a problémás részeket az olvasható binlog kimenetben és azt futtattatom le a SLAVE-vel.

Kérdés, hogy a bináris loghoz viszonyítva minden információ benne van-e a mysqlbinlog paranccsal visszakapott SQL szkriptben, vagy veszteséges; és az hogy alkalmazható-e ilyen formában:

mysqlbinlog relaylog.000001 | my_convert_script | mysql -h localhost

Ignorált adatbázis, tálba nincs, de több adatbázist is tartalmaz a binlog, és mixed formátumú (igaz, az átírkálásokat a statement formátumú részekben kell elvégezni).

Gyakorlati megvalósításképpen gondoltam arra is, hogy 1. minden binlog utasítást a fenti formában kapna, vagy 2. ha a SHOW SLAVE STATUS hibát jelez, az adott pozícióban lévő részt szedném csak ki a mysqlbinlog paranccsal és konvertálnám át és futtatnám le, utána a pozíció (és esetlegesen a relaylog fájl) léptetésével újra elindítanám a SLAVE-et.

update
nagyszerűen gyakorlatias és probléma-orientált a HUP közössége, segítőkészek vagytok a rendszerek rendszergazdabaráttá tételében, és a problémákat okozó folyamatok leghamarabbi ponton történő javításában.
ugyanakkor jelen kérdésemmel (és a legtöbb kérdésemmel, amit nem úgy kezdek, hogy "mit csináljak másképp") csupán a mysql és különböző verziói működésére vagyok kiváncsi egy olyan elméleti szituációban, amikor a replikáció SQL Threadjét kéne emulálni mysqlbinlog parancs kimenetének végrehajtásával.