"-labels ( ez egy olyan varchar lenne, ahol a label_id-k vanak tárolva, például ilyen formátumban: |1|34|45|54| ) - magyarul, minden egyes label_id | | között lenne."
Ha hatékony megoldást keresel, egyből le kéne, hogy essen, hogy ez aztán garantáltan nem lesz az.
Amúgy sem értem, minek kéne ilyen pipe-pal elválasztva tárolnod, amikor létrehozol neki egy külön táblát... A product id-val kéne összekapcsolnod, aztán kész.
Csak gondolj bele, hogy hogyan tudnál ezek között hatékonyan keresni, ha stringben egybe van b@szva... hatékonyan sehogy.

Sk8erPeter

Ha kocka vagy a szó jó értelmében, akkor mindenhez PostgreSQL-t érdemes használni (már persze MySQL összehasonlításban, én egyébként MS SQL-re szavaznék a jelenlegi SQL felhozatalban).
Ha nem akarsz belemélyedni, csak annyit akarsz, hogy menjen, és az alapfunkciókat használod, akkor a MySQL elsőre szvsz jobban kézre áll.

Én kérek elnézést!

"Ha kocka vagy a szó jó értelmében, akkor mindenhez PostgreSQL-t érdemes használni"
Miért?
(Most nehogy attól tarts, hogy én védelmezni kívánom bármelyik SQL-nyelvet, mert eszem ágában sincs, csak kíváncsi vagyok a szempontokra. )

[ Szerkesztve ]

Sk8erPeter

Mert a motorháztető alatt, illetve skálázhatóság (gondolok itt elsősorban a fürtőzésekre, azaz horizontális skálázhatóságra) szempontjából a PostgreSQL sokkal többet tud, sokkal finomabbra hangolható.
És ahogy mondtam, az már más kérdés, hogy a userek 99%-a ezeket a MySQL-hez képest extrának számító feature-öket az életben soha nem is fogja kihasználni.
Ellenpéldának meg ott van a Facebook, de ők már rég agyonhack-elték mind a PHP-t, mind a MySQL-t, és jó példák arra, hogy szarból is lehet várat építeni, ha erre több milliárd dollárod van.

Másrészt bevallom nem vagyok 100%-osan naprakész ez ügyben. Postgre-nal lemaradtam a 9-es főverziónál, MySQL-t érdemben utoljára 5.4-eset használtam. Szóval lehet, hogy közben MySQL lépett előre, bár magának az Oracle-nek sem érdeke, hogy igazi konkurenciát támasszon házon belül az Oracle DB-nek.

Én kérek elnézést!

OK, köszi a választ! Még nincs tapasztalatom Postgre-val, kíváncsi vagyok rá.

Sk8erPeter

A MySQL vs. Oracle összehasonlításnak nincs értelme. Nem ugyan arra a piacra készült így nem lehetnek egymás konkorensei. Sokat fejlődött a MySQL mióta az Oracle átvette a Sun-tól.
MSSQL vs. Oracle vs. PostgreSQL ennek az összehasonlításnak talán már több értelme lenne.

Miért is nincs értelme az összehasonlításnak? Ráadásul nem is hasonlítottam össze, tényt közöltem, hogy az Oracle tudatosan tartja bután a MySQL-t. Persze fejlődget, de tudatosan hagyják ki belőle azokat a funkciókat, amitől horizontálisan jól skálázható, központilag könnyen üzemeltethető lenne (backup, mirror, stb...), adattárházként használható, azaz amitől a nagyvállalati szegmens számára vonzó lehetne.
Mivel a kolléga erre volt kíváncsi, illetve mások is kérdezték, hogy miben jobb a PostgreSQL. Pont a fentiekben jobb (minusz adattárház, mert az abban sincs igazán).
Ettől még nagyon is össze lehet hasonlítani mindent mindennel, pláne amikor DB platform választás előtt áll valaki.
Én is csak mellékesen jegyeztem meg, hogy én személy szerint nem választanék se MySQL-t, se PostgreSQL-t. Manapság egész jó ingyenes verziói vannak az Oracle db-nek, ennél többet tud az ingyenes MS SQL. Induláshoz ezek bőven elegek. Aztán, ha bejött a nagy üzlet, akkor el lehet gondolkodni ezek fizetős verzióin, illetve amit nagyon ajánlok az a felhő. Amazonws, azure, google felhője, már mindenkinek van felhő szolgáltatása, és szépen csökkengetnek az árak.

Én kérek elnézést!

Nem tudom fejlesztőként vagy üzelemtetőként töltöd a munkaóráidat adatbázisok között?
Beépített függvényekben az Oracle sokkal szerteágazóbb, testreszabhatóbb, részletesebb megoldásokat kínál, míg az MSSQL ebből a szempontból sokkal elnagyoltabb. (Hozzátenném, hogy napi szinten fejlesztek MSSQL2008 alatt.) Pl.: Random függvény Oracle-ben és MSSQL-ben

Ui: Nagyon szeretek T-SQL-ben dolgozni, de tény hogy megvannak a maga korlátai. Ez Oracle-nél is így van de ott "komolyabb"* megoldásokkal lehet találkozni.

*A szakmai szememnek tetszőbb, szakma által jobban elfogadott, konvenció követőbb

[ Szerkesztve ]

hogy ette az adatbázis szerver a kliensek memóriáját?

egyébként az XE korlátai: 1 CPU, 1 GB memória, 11 GB felhasználói adat, tehát ennyire eszi

VPS-re nem érdemes Oracle-t rakni, mert nem lesz valami sebes és elég drága lesz a VPS config ára hogy menjen egyáltalán az OracleDB. Lásd itt már kitárgyaltuk a témát.

"Kliensekre volt felrakva, a db szerver..."

jó, az iskolai (egyetemi) géppark nem a sebességéről híres

"Csak az a gondom, hogy én szeretnék VPS-t bérelni, amin futna olyan 4-6 oldal lenne rajta, 1 mongodb és egy rdbms is.
1GB ram, 2magos cpu, 50GB-ra menne, és nem tudom mennyire bírná a szerver. Esetleg ilyen tapasztalatod van ezügyben?"

ezügyben sajnos nincs
1 GB memória elég kevés, de ha ezek valami minimál oldalak, akkor elképzelhetőnek tartom, hogy elég lehet
kérdés, hogy erre tényleg kell-e neked Oracle, vagy elég valami pehelysúlyú rdbms

lakisoft: én nem emlékszem rá hogy ez így ki lett volna tárgyalva

Ez az átvinni dolgot migrálásnak hívják és elég kemény tud lenni ha adatbázis specifikusra van megírva a szerkezet is. MySQL -> Oracle migráción dolgozom éppen és elég kemény dolgok adódnak néha. .

Az adatbázis szerkezetétől, komplexitásától függ.

Tárolt eljárások lesznek? vagy egyéb logika lesz beépítve?

[ Szerkesztve ]

"suli-ban" sulitiltás?
A tárolt eljárás pedig sokszor jó kis segítség tud lenni, például ASP.NET-ben. Amúgy a tárolt eljárás arra is jó, hogy nem kell a query-vel elrondítanod az alkalmazásod kódját, hanem az adatbázisban tartod azt, aminek épp ott a helye, vagy amit úgy érzel, nyugodtan rábízhatsz az adatbázisra, és azt terheled a feladat megoldásával, stb. Meg így adhatsz neki egy jó beszédes nevet, aztán meghívhatod az alkalmazásod kódjából a megfelelő paraméterek átadásával. Csomó mindent el lehet intézni benne, ami csúnya lenne alkalmazásból, vagy épp nem akarsz ORM-et igénybe venni rá, satöbbi.

Sk8erPeter

Fejlesztőként, de néha muszáj valamennyit üzemeltetnem is.
Abszolút nem szeretnék belemenni MS SQL, Oracle flame war-ba. Vannak olyan képességei az Oracle-nek, amikben valószínűleg jobb (a motorháztető alatt értem), de az általad írt példák éppen nem ilyenek, hanem tökéletesen szubjektív szintaktikai példák.

Én kérek elnézést!

"itt anti tárolt eljárás szellemiség van" - szóval gányoltok, vagy annyira kicsiben játszotok.
Mondok egy gyors példát, hogy mikor jó a tárolt eljárás és egyáltalán nem csak ASP.NET-nél
Egy táblába be kell szúrnod egy adatot, más táblák adainak függvényében.
Ezt megoldhatod úgy, hogy fogod, lekéred az adatokat 3-4 táblából a webszerverre, majd kódban megvizsgálgatod őket, ezek alapján összeraksz egy insert-et, és beszúrod az adatokat. Ez így mondjuk 4-5 DB-hez nyúlást jelent, mindig felépíted/feléleszted a kapcsolatot, az adatok jönnek mennek feleslegesen, kezeled a kivételeket stb...

Ehelyett írhatsz egy tárolt eljárást, amivel SQL DB-n belül tudod megoldani ugyanezt. Egy adatbázis hívással, nulla felesleges adatmozgással.

Én kérek elnézést!

Terhelés alatt is nézted?

szerintem ez működne:

SELECT t.normal_ar, t.normal_ar * 0.9
FROM tabla t
ORDER BY 2

select cikk, ár, akció, ár+akció from tábla
order by ár+akció

A + lehet - vagy / vagy * is, attól függ milyen korrekciót használsz.
Erre gondoltál?

Antonio Coimbra de la Coronilla y Azevedo, bizony!

Ahogy fordfairlane is írta, a CASE WHEN ... THEN ... END szerkezet a megoldás a problémádra, ha nem akarsz külön oszlopot erre fenntartani.

Ne adj egyszerre több típusú kedvezményt - általában egyébként sem összevonhatók a kedvezmények (vagy ha van több féle, akkor ne keverd őket, hanem számold ki melyik ár az alacsonyabb és jelenítsd meg azt).

Amúgy :
SELECT ..., Vetelar, (Vetelar - Engedmeny) * (1 - Kedvezmeny) AS KedvezmenyesAr, ...

Ahol:
Vetelar - az eredeti vételár pl. 30 000
Engedmeny - a termék (vagy terméktípus) engedménye, pl 1 000
Kedvezmeny - a termékre (terméktípusra) adott kedvezmény pl. 10% (0.1)
KedvezemenyesAr - a végső ár az összes levonással együtt...

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Ez tök jó, amíg mondjuk forintot használsz (de mondjuk euróban egy 10 EUR is elég nagy kedvezmény tud lenni). Én ha egy változóban tárolnám akkor monjuk a negatívok lennének a levonandók, a pozitívak a százalékok - csakhogy véletlen se kelljen keveredniük.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A discounts táblában fel kéne venned mégegy mezőt, ami a kedvezmény típusát jelölné (százalékos, konkrét érték stb.), így a discounts.discount értékét nem kellene figyelned. A CASE WHEN utasításban pedig a kedvezmény típusát jelölő mező értékét vizsgálnád. (Ez alapján lenne szorzás/osztás vagy összeadás/kivonás vagy egyéb művelet.)

Hogy tudnám megoldani egyszerűen és kényelmesen azt, hogy ütemezetten fájlokat töltsön fel az SQL szerverem egy FTP tárhelyre? Én az Integration Services-nek az FTP Taskjára gondoltam, mint megoldás. Szükségem lesz az Integration Services-en belül másra is? Az FTP Task ütemezhető? Nem foglalkoztam még ezzel a témával és most se öltem még bele sok időt, de gondoltam érdeklődök mielőtt próbálkoznék, tesztelgetnék.

Ne várjunk a nevetéssel, amíg boldogok leszünk. Különben félő: meghalunk anélkül, hogy nevettünk volna. /La Bruyére/

Agent-re lehet még szükséged (job létrehozás stb stb.). Úgy látom MS SQL Servert használsz. Melyik verziót?

Jelen esetben SQL Server 2008 R2. Egyébként SQL Server 2000-től SQL Server 2008 R2-ig vagyok kénytelen foglalkozni az SQL Serverekkel. Várhatóan bővül a sor nemsokára az SQL Server 2012-vel.

Akkor, ha jól értem, csak szimplán Integration Services-ben FTP Task-ot használok, aztán azt ütemezem Management Studióban Job-bal. Mondjuk nem tudom, hogy FTP Task-kal egyszerre több fájlt is lehet-e küldeni vagy ahhoz trükközni kell, de ma utána nézek ennek.

Ne várjunk a nevetéssel, amíg boldogok leszünk. Különben félő: meghalunk anélkül, hogy nevettünk volna. /La Bruyére/

"A kategóriákat '|' jellel elválasztva rakom be az adatbázisba"
Ez az, amit kerülj el, válaszd szét rendesen. Sok sort fog eredményezni, de az nem baj. Annyi sor lesz, ahány taget/terméket/akármit akarsz hozzákapcsolni az adott entitáshoz.

Leegyszerűsítve:

termékek tábla
-----------------------
id ; termék neve; kategóriák
123 ; én termékem ; kategória1|kategória765

HELYETT

termékek tábla
-----------------------
id ; termék neve
123; én termékem

kategóriák tábla
-----------------------
id; kategória neve
1; kategória1
765; kategória765

termékek-kategóriák összekapcsoló tábla
-------------------------------
id; termék_id; kategória_id
1; 123; 1
2; 123; 765

Sk8erPeter

"A kategóriákat '|' jellel elválasztva" - eddig olvastam...

Én kérek elnézést!