Vita:Adatbázis-kezelő rendszer
|
Ez a szócikk témája miatt az Informatikai műhely érdeklődési körébe tartozik. Bátran kapcsolódj be a szerkesztésébe! | ||
| Bővítendő | Ez a szócikk bővítendő besorolást kapott a kidolgozottsági skálán. | ||
| Nagyon fontos | Ez a szócikk nagyon fontos besorolást kapott a műhely fontossági skáláján. | ||
| Értékelő szerkesztő: Zafir (vita), értékelés dátuma: 2012. május 31. | |||
| |||
A megjegyzés, miszerint az adatbázis-kezelés jellemző példája a számlázás, az erőforrás-kezelés nagyjából olyan erejű és pontosságú kijelentésnek érzem, mintha valaki azt mondaná, a motor jellemző példája a szállítmányozás, a repülés, és a tengeri hajózás. Ha jól sejtem, az adott módosítás valójában azt akarja mondani, hogy vállalatirányítási rendszerek világában tipikusan adatbázis-kezelőkre célszerű támaszkodni, illetve azok magja jellemzően egy adatbázis-kezelő. De ez nem magyarázza a szócikket, nem tekinthető "jellemző" felhasználásnak, hiszen csak közvetett módon vannak kapcsolatban - akárcsak a tengeri hajózás és a motor. A fentiek tükrében töröltem a javasolt módosítást.
Hasonlóan javaslom a korábbi, Lodoktor által definiált fogalomrendszer használatát. Egyrészt fogalmilag tisztább, ugyanis nem keveredik benne össze nem tartozó fogalmak sora. Az alkalmazást ugyanis olyan felhasználói programokra szokás alkalmazni, amely valamely konkrét cél érdekében végez feladatokat. Általános célú programokat sosem nevezünk alkalmazásnak. Egy játékprogramot lehet alkalmazásnak nevezni, egy operációs rendszert, adatbázis-kezelőt nem. Ezzel összhangban, az alkalmazásnak, vagy egy szoftverrendszernek - mert az adatbázis-kezelő az(!) - moduljai esetében beszélhetünk API-ról (Application Programming Interface), ami mindig, sőt MINDIG programozási felület számára biztosított. API-n keresztül a szoftver módosítható, modulok adhatóak hozzá. Az SQL interpretert API-nak tekinteni olyan dolog, mint a mikrohullámú sütőben melegítést konnektornak (vö. dugalj) nevezni.
Hasonlóan fogalmi keveredést okoz, ha valaki az adatbázis(ok)ra épülő alkalmazásokat összekeveri az adatbázis-kezelővel. A mobil telefon telefonkönyv-kezelője nem adatbázis-kezelő, ahogyan jukebox sem az. Senki sem tekinti annak. Pedig az utóbbi is szoftveralkalmazás és "CD adatbázist" kezel. Egy fogalom meghatározásánál a "nagy mennyiség" szintén nem lehet tényező. Mi az a nagy? Videostream vagy térképészeti adatbázisoknál 1 petabájt is lehet kicsi, egy számlázási rendszernél olykor 1 megabájt is nagy. A korábbi megfogalmazás sokkal objektívebb volt.
Adatbázis-kezelő redirektvitalapról átrakva
szerkesztés- 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)
Törlési megbeszélés lezárt jegyzőkönyve
- Az alábbi törlési javaslatot archiváltuk. Kérjük, ezt a megbeszélést már ne módosítsd! A további hozzászólásokat a cikk vitalapjára írhatod. Ezt a lapot már ne szerkeszd!
Az eredmény: A téma vitathatatlan szakértőjeként úgy döntöttem, hogy mindkét cikk tartalmaz a másikból hiányzó értékes anyagot, összedolgozandó, a törlési eljárás lezárva, összedolgozásig megmaradt – Bennó 
(beszól) 2007. május 21., 14:18 (CEST)
A DBMS, amiről a szócikk szól, valójában az adatbázis-kezelő rendszer, erre pedig külön szócikk van. Az alábbi cikkben amúgy keverednek az adatmodell(ezés), adatbázis-kezelés és a logikai adatmodellek típusainak részletezései.Lodoktor 2007. május 10., 19:15 (CEST)
- szerintem erre használhatod az
{{összevonandó}}(?) sablont is, vagy egyszerű átirányítást lehet belőle csinálni. -- nyenyec ☎ 2007. május 11., 16:33 (CEST)
törlendő A tartalma hasonló a másikhoz, ellenben tartalma láthatóan sokall-sokall kisebb, és egyébbként sem kell két külön szócikk ugyanannak. --Beyond silence 2007. május 11., 17:27 (CEST)
- Biztos fel lehet hasznalni az anyagot mas cikkbe -- osszevonando inkabb.--Kádár Tamás Megint vitatkozol?? 2007. május 12., 12:11 (CEST)
- Ha tényleg "keverednek az adatmodell(ezés), adatbázis-kezelés és a logikai adatmodellek típusainak részletezései." akkor
törlendő ( mert lila gőzöm sincs, hogy mi az)--Immanuel 2007. május 16., 21:33 (CEST)
- A fenti megbeszélést archiváltuk. Kérjük, további hozzászólásokat már ne írj hozzá! Ezt a lapot ne szerkeszd!