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)


Based on work by Slate és