Vita:Adatbázis-kezelő

A Wikipédiából, a szabad lexikonból.

  • 2. bekezdésre ellenpélda az összes desktop adatbáziskezelő, melyek se hálózati elérést se többfelhasználós oprendszert nem feltételeznek.

pl: sqlite, mssql-de,db3

Mit javasolsz, hogyan különböztessük akkor meg a Database engine (adatbázis? adatbázis motor?) (mint az sqlite, db2) a Database Management System-től (adatbáziskezelő? adatbáziskezelő rendszer?) (mint a psql, sap)? Nyilvánvalóan nem ugyanarról írtunk. Én örülnék, hogy ha a magyar cikkek konzisztensek lehetnének a többi nyelvvel, nem beszélve arról, hogy az sem baj, ha logikusak. --grin
Vastaggal írok hogy látszon. Szerintem a Database engine az adatbázis motor ami meghajtja az adatbáziskezelőt és erősen technikai kifejezés. Kb az a különbség mint a pdfparser/renderer és a pdf olvasó közt. Szerintem az adatbáziskezelő funkciói a konzisztens adattárolás, karbantartás és kiszolgálás, valamint security. Én is örülnék ha konzisztensek lennének a cikkek, ezért írogatok. A többi nyelven azt érted hogy itt a wikipédiában már valahogy valaki elkezdte és nekünk ahhoz kéne igazodni? --Slate 2004 február 3, 20:19 (CET)
  • 3. bekezdésben: Nem igaz hogy az adatbáziskezelők elérhetőek szabványos felületről (SQL CLI). A relációs adatbáziskezelőknél tény hogy ez volt az eredeti SQL szabvány célja, de az üzleti érdek ez ellen hatott, ezért nem is valósult meg. Ezért írtam az SQL részben a nyelvjárásokról.
Nem értek egyet; egyrészt az SQL szabvány - a nyelvjárások ellenére - nagyrészt konzistens, és a különbség az SAP és a PostgreSQL között jóval kisebb, mint mondjuk a windows API és az X-Windows API között (amire azt mondanám, hogy nem szabványosítottak [egymással]), másrészt tendencia a szbványoknak való minél teljesebb megfelelés. --grin
Az SQL tényleg szabvány és tényleg konzisztens, és az implementációk tényleg jobban hasonlítanak mint a fent említett példában. De nem portábilis annyira mint pl a java. A tendencia rálátásához kicsi vagyok, csak azt tudom hogy minden általam ismert gyártó tanácsadói nem ezt mondják, Én már sokat küszködtem alkalmazások átültetésével egyikről a másikra. Egyébként erre utal a [1] hely is(vendor lock-in). De lényeg az optimizmus:) Valahogy biztos meg lehet fogalmazni úgy hogy benne legyen az, hogy senki ne számítson arra hogy pl a mysqlre írt scriptek egy az egyben futni fognak Oracléban. --Slate 2004 február 3, 20:19 (CET)
  • Nem relációs adatbáziskezelőknek általában nincs ilyen felülete

Példa: Btrieve, Berkeley db2,db3

  • Ha pedig APIra gondolunk akkor végképp nem igaz, ebben az estben az ODBC és a JDBC biztosít ilyen jellegű felületet, de az is csak általában relációs adatbáziskezelőkre és nem teljeskörűen, ezért is vannak:

http://www.linux.org/apps/AppId_7892.html http://libdbi.sourceforge.net/

Akkor javaslom, hogy ne általánosítsunk; minden részbe bele lehet írni, hogy az adott csoportnak van-e szokásos, elfogadott API-je, vagy több, elterjedt szabványos felülete. Az, hogy fajtánként bontjuk, erre nagyon jó lehetőséget ad: írhatjuk, hogy a nem relációs adatbázis-kezelők ilyenek, a relációsak meg amolyanok, emitt az ODBC elterjedt, amott meg a C API-je, amit XYZ publikált.
Szerintem lehet általánosítani, néhány szó az sql-ről néhány szó a c apiról, meg majd írok a spec adatbázisokhoz, mert olyan is van (Oracle Express, SAS), amelyeknek szintén saját nyelvük van, ami nem SQL és mégis adatbáziskezelők.--Slate 2004 február 3, 20:19 (CET)
Én amúgy DBI-t használok, és emiatt jelezhetem, hogy számomra meglehetősen szabványosnak tűnnek a DBMS-ek. :) --grin 2004 február 3, 11:22 (CET)
boldog ember --Slate 2004 február 3, 20:19 (CET)
...amúgy jobb érzés lenne vitatkozni/beszélgetni, ha tudnám, hogy kihez beszélek. De persze ha az anonimitást favorizálod, legyen. -g
done --Slate 2004 február 3, 20:19 (CET)
Javaslom nézd meg: [2] persze nem akarok plagizálni és a marketinget is ki lehet hagyni. Majd ha lesz időm írok javaslatot is. hali --Slate 2004 február 3, 20:19 (CET)