Adatbázis: SQL, XML DB

Sziasztok!

PHP-ben fejlesztek egy leltár programot amiben van egy leltári szám, ami 2 féle képpen generálódik:
1. Év+Hónap+futó sorszám. Pl.: 11050001, 11050002, 11050003...
2. Csak futó sorszám, Pl.: 00000001, 00000002, 00000003...

Ezen az oszlopon index van, és mellette van egy auto increment primary key is.

A Probléma a következő: ebbe a táblába sok insert történik egy időben, mert a php progit sokan használják egyszerre. A php egy mysql userrel csatlakozik a mysql-hez és hajtja végre a lekérdezéseket. Ebben az oszlopban adott esetben előfordulhat duplikáció, mert van olyan hogy egy leltári számon kell tárolnom szorosan összefüggő termékeket. Ez miatt nem lehet unique, illetve a fentebb leírt leltári szám generálás miatt auto increment sem.

Amikor új elemet viszek a leltárba akkor ki kell olvasnom az adott számozási eljárásnak megfelelő legmagasabb leltári számot, majd az INSERT-nél ehhez adok egyet és beszúrom a többi adattal együtt. Ezzel az a probléma hogy ha az adott pillanatban más is elindít egy beszúrást, akkor ugyanazt a legmagasabb leltári számot fogja beolvasni, majd növelni egyel mint a konkurens user, és így ugyanarra a leltári számra kerülhet 2 teljesen külömböző termék.

Hogy lehet ezt kiküszöbölni?

A kovetkezo problemara keresek esszeru megoldast:

adott egy script, ami maillog-ot olvas File::Tail-lel, es a feldolgozott infokat adatbazisba tolja (az adatok jellege szerint) kb. 3 db (indexelt) tablaba. Worst case tablankent havi 10M rekord gyulne ossze az adatbazisban.

A kerdes az, hogy milyen storage engine-t valasszak, ha keresni is kell benne, tovabba naponta 1x torolni az 1 honapnal regebbi rekordokat, es mindezt ugy, hogy ne szakadjon bele se a gep ill. se a mysql demon a csomo insert-be, ill. a select-ek is ertelmes sebesseggel fussanak le?

Az 'archive' engine nagyon megtetszett, csak egy feature-t nem tud: delete, ami azert fajo hiany erre a feladatra...

Ha csak jobbat nem mondtok, akkor marad az 'archive' storage engine ugy, hogy naponta uj tablat keszitek pl. table_YYYYMMDD, es ami nem kell, azt eldobom drop-pal. De ez azert nem tul elegans hackeles...

Es meg egyet nem tud: indexeket, ami azt is jelenti, hogy az archive engine-t el kell felejteni...

Ezt az e-mailt kaptam (a lényeget másoltam csak ide):

"Intézetünk belső adatbázis rendszere fejlesztésre szorul, jelenleg egy DOS-os programot használunk.

Olyan egyetemi hallgatót keresek, aki a meglevő adatbázis struktúrát és az egész adatbázist át tudná ültetni SQL/PHP-ra. Szükség lenne néhány új funkció kialakítására is."

Arra lennék kíváncsi, hogy egy ilyen munkának mekkora a piaci értéke, és úgy egyáltalán mekkora munkával jár egy ilyen?
Elképzeléseim vannak, de szeretném ha olyanok akik ezzel foglalkoznak azok is véleményt mondanának erről.

Zsolt

Szerk: Aki az e-mailt küldte azt szeretné, ha ingyen végeznék el a munkát. Ezért is keres egyetemistát a projektre. Én nem rendelkezek a kellő szabadidővel, hogy megcsináljam, ingyen egyébként se tenném. Igazából az érdekelt volna, hogy mennyit akartak ezzel spórolni, de amint látom ennyi információból nagyon nehéz megtippelni a várható árat. Gondolom abból indultak ki, hogy minden munka annyit ér amennyiért elvállalják, és hülyék lennének fizetni, ha valaki ingyen is megcsinálja.

Sziasztok!

A tárgyban említett postgresql hibát kaptam, és nem értem miért, légyszi segítsetek megérteni a dolgot.

íme a hiba:
SQL state: 42P17
Context: SQL statement "CREATE INDEX idx_search_aggregate_date_apr_1206 ON infx.search_aggregate_1206 USING btree ("start_date")
WHERE ((start_date >= (to_char(2012, '9999') || '-04-01')::date) AND (start_date <= (to_char(2012, '9999') || '-04-30')::date))"

Ami még érdekes, hogy eddig be volt égetve az év, és úgy tökéletesen működik:
CREATE INDEX idx_search_aggregate_date_apr_1206 ON infx.search_aggregate_1206 USING btree ("start_date")
WHERE ((start_date >= '2012-04-01'::date) AND (start_date <= '2012-04-30'::date))

egyébként ez egy tárolt eljárásban van. A megoldás az lett, hogy az évet nem az indexben alakítom át:
start_date >= (to_char(' || year_in_index || ', ''9999'') || ''-04-01'')::date
hanem még előtte:
select into year_in_index to_char(next_year, '9999');
start_date >= ''' || year_in_index || '-04-01''::date

Ettől függetlenül nemnagyon értem miben más ez a megoldás.

Köszi az építő válaszokat.

Sziasztok!

Egy ideje böngészem a netet, de sajnos nem leltem megoldásra, ezért hátha ti tudtok nekem segíteni.

Van 3 táblám, amelyből csináltam 1 nézetet.
A nézetre pakoltam egy INSERT szabályt (azaz beszúrás esetén EZT hajtja végre)

A szabály így néz ki:

1.) Beszúr egy sort egy táblába, amelynek első mezője egy SERIAL
2.) Beszúr egy sort a másik táblába, amelyben egy mező FOREIGN KEY-ként hivatkozik az előbb használt SERIAL mező értékére

és itt el is akad a dolog: nem létezik a hivatkozott idegen kulcs az első táblában.

Azt megpróbáltam, hogy a két INSERT közé rakok egy COMMIT; parancsot, de nem fogadta el.

Az ötleteket, javaslatokat köszönettel várom.

Sziasztok!

Először is Kellemes ünnepeket mindenkinek!

Bocsi a valszeg buta kérdésért. Arról van szó hogy van egy lamp környezet, ahol a mysql lekérdezéseket php script végzi, mysql adatbázist kívülről nem kívánom elérni, max úgy hogy ssh-val bejelentkezem.
Ha portscan-t futtatok akkor a mysql portja (3306‎ asszem) open statuszba van. ez normális?
Akkor is nyitottnak kell lenni ha localhost a php interpreter kérdez tőle?
A mysql configjába tudom hogy be lehet állítani hogy csak localhoston listeningeljen de attól még az nyitott port lesz nem?

Üdv

Van egy tábla benne 478987 rekord.
Jelenleg a név mező varchar(72) formátumú.
Az ajánlás azt mondja Tinytext notnull lenne a jobb.
Index van rá, bár így is elég lassú egy like lekérdezés.
(tudom a like-nál nem használ indexet)
Szóval a kérdés, gyorsabb lenne-e a lekérdezés tinytextnél?

pch

Üdv!

Egy lite CRM-hez kellene adatbázist készíteni, azonban egy táblát nem tudok sehogy sem létrehozni. errno:150 hibaüzenetet dobál a szerver. Először CLI-n próbáltam létrehozni, aztán a sok sikertelenség után a mysql-admin GUI-jával próbáltam, az alábbi kódot generálja:
CREATE TABLE ugyfel (
id INT NOT NULL AUTO_INCREMENT,
nev VARCHAR(30) NOT NULL,
statuszid INT NOT NULL,
tipusid INT NOT NULL,
telefon VARCHAR(30) DEFAULT NULL,
fax VARCHAR(30) DEFAULT NULL,
email VARCHAR(100) DEFAULT NULL,
weboldal VARCHAR(100) DEFAULT NULL,
ertekesitoid INT NOT NULL,
cegjegyzek VARCHAR(20) DEFAULT NULL,
adoszam VARCHAR(20) DEFAULT NULL,
bankneve VARCHAR(100) DEFAULT NULL,
swift VARCHAR(10) DEFAULT NULL,
szamlaszam VARCHAR(30) DEFAULT NULL,
holtalaltrank VARCHAR(300) DEFAULT NULL,
miertminket VARCHAR(300) DEFAULT NULL,
miertnemminket VARCHAR(300) DEFAULT NULL,
feljegyzesek VARCHAR(300) DEFAULT NULL,
PRIMARY KEY (id),
CONSTRAINT fk_statusz FOREIGN KEY fk_statusz (statuszid)
REFERENCES ugyfel_statusz (id)
ON DELETE RESTRICT
ON UPDATE CASCADE,
CONSTRAINT fk_tipus FOREIGN KEY fk_tipus (tipusid)
REFERENCES ugyfel_tipus (id)
ON DELETE RESTRICT
ON UPDATE CASCADE,
CONSTRAINT fk_ertekesito FOREIGN KEY fk_ertekesito (ertekesitoid)
REFERENCES munkatarsak (id)
ON DELETE RESTRICT
ON UPDATE CASCADE
)
ENGINE = InnoDB
CHARACTER SET utf8 COLLATE utf8_hungarian_ci;

A hivatkozott táblák már léteznek, az id mezők primary key-jel lettek létrehozva.

Google találatok között olyan megoldási ajánlatot találtam csak, mi szerint létre kell hozni egy indexet a tábláról, de ez sem segített. dev.mysql.com sem igazán akart barátkozni velem.

Szerver: MySQL 5.1.49-1ubuntu8.1
Host: Ubuntu 10.10

Mi a gond?

Van egy szerver, amiről a mysql állományokat sikerült megmenteni. Egy szűz linuxon felraktam egy mysql szervert és oda raktam át a mysql állományokat. A MyISAM táblákkal nincs is baj, egyszerű bemásolás után működnek. Viszont az InnoDB táblákat nemlétezőnek deklarálja lekérdezéskor (látja, hogy ott vannak, de nem tudja lekérdezni). Annak ellenére sem, hogy a MySQL rendszeradatbázis táblái is helyre vannak állítva.

Hello!

Egy kis segítségre lenne szükségem.Feltelpítettem egy centos5.5-re egy oracle 11gr2EE-t ez alapján http://planetvm.net/blog/?p=1353.
Teljes siker hiba nélkül fel is települt,persze nem az első nekifutásra.:)

A probléma ott kezdődött, hogy ez EM webes felületén nem tudtam belépni,semmelyik
felhasználóval, úgyhogy az lenne az első kérdésem, hogy hogy lehet belépni?:)

A másik pedig, hogy hogy lehet újraindítani a db-t?:)

ui.:Elég newbie vagyok, úgyhogy pls óvatosan.:)
ui2.:Az online doksi nem segített,vagy csak lehet rossz helyen kerestem.

Kösz,
Gyuri