"sajnos sokat az OOP-t csak divatossága miat használják, s nem azért mert a táblák nem lennének használhatóak egy adott problémánál."
Az OOP-t azert hasznaljak, hogy elfedd a lenyegtelen dolgokat az osztalykonyvtar felhasznaloja elol. Vagyis, ha te csinalsz egy publikus service-t, aminek mondjuk a kovetkezo metodusai vannak:
akkor a felhasznalot egyreszt nem erdekli, hogy ezek mogott milyen tablak vannak (ha egyaltalan tablak vannak, es nem mas serviceket hiv meg), masreszt jobb, hogy nem tud rola, mert lehet, hogy a megvalositas le lessz cserelve kesobb, ugy, hogy a 'user'-nek nem kell a kodjahoz nyulnia.
"a lekérdezések 80%-a leírható egyetlen lekérdező nyelv (nem feltétéenül SQL) segítségével"
Akkor ez a nyelv nem lesz tul hatekony, mert a tapasztalataim szerint a lekerdezeseknek 100%-a leirhato SQL segitsegevel, mivel eddig mindig sikerult...
Visszaterve az IMAP LDAP kerdesedre: Nem te vagy az elso, aki rajott arra, hogy kulonfele directory service-k nagyon hasonloak. A dolog onnan indult ki, hogy a cel az volt, hogy az LDAP legyen a szabvany. Ez nem teljesen jott ossze. Ezert pl. a SUN-nak van egy olyan API-ja, amelynek a neve az, hogy JNDI. (Java Naming and Directory Services). Ez az API Abstract osztalyokbol all, es ezt implementaljak a kulonfele service providerek, pl LDAP,... Igy ugy tudsz programot irni, hogy az fuggetlen lesz a directory service-tol, amit hasznalsz.
Egyébként meg akinek van kedve, azzal leülnék sokkal alaposabban is, gondolkozni, tervezni. Írtó jó lenne olyanokkal alkotni akik átérzik a dolgog értelmét, fontosságát, stb. Úgy látom AntiSystem és Attoparsec kicsit már ráharapott, s a többiek is érdeklődnek egy kicsit.
Attoparsec-nek azt válaszolnám, hogy az objektum-orientáltságot én is a "nagy terv" részeként látom, de csak a sémák kezelésébem. Hogy az "Ember" táblát lehessen örökíteni "JóEmber"-ré, ahol újabb oszlopok (tulajdonságok jelnnek meg).
Meg arra is rá kell mutatnom, hogy a tábla és összefüggés alapú adatbáziskezelés nem is tér el különösebben az objektum alapúaktól, s hogy nagyrészt szintaktikai különbség van, s hogy sajnos sokat az OOP-t csak divatossága miat használják, s nem azért mert a táblák nem lennének használhatóak egy adott problémánál.
Aztán még azt is megjegyezném, hogy ha rá akarsz kérdezni, hogy egy adott objektumkiszolgálón milyen osztályok vannak, melyek rendelkeznek FileOpen metódussal, akkor rájössz hogy nem is olyan rossz ötlet az SQL. Mert a osztálykönytáron való keresztül-bogarászás helyett (rengetek kérdés-válasz forgalom a hálózaton) egyetlen paranccsal a megfelelő eredményre juthatnál.
Összefoglalásul tehát azt mondom, hogy valójában hasonló dolgoról álmodunk, csak más múlttal. Én azt mondomn hogy a te objektuom igényed jól kifejezhetőek db trükökkel. Egyébként fordítva is, de akkor te nekilátnál ListSources meg ListClasses meg ListMetadata metódusokat írni, ami szerintem szükségtelen, mert mindkettő egy-egy táblát adna vissza. Akkor meg minek külön metúdus, csak arról van szó hogy eltérő táblából kérdezek le adatokat.
A 20/80-as szabály, ami egyébként olyasmit takar, hogy a dolgok 80%-ának megvalósításához a teljes munkából 20%-nyi időt fordítunk, mig a maradék 20%-on tökölünk az összidő megmarad 80%-ában. (Egyesek a 10/90-es arányt tartják reálisnak)
A logolással kapcsolatban nem értem miféle százalékokra jutottál. Én arra értettem, hogy úgy unblokk a számitastechnikai feladatok 80% százaléka lefedhető egy technikailag nem olyan nagy komplexitású (20% szoftver IQ) eszközkészlettel. Az alkalmazási területek maradéka (videoszerkesztés, 3d animáció, tudományos modellezés) esetén természetesen rendgeteg irtó bonyolult célszerszámra van szükség (80% szoftver IQ).
Ezt az eszközkészletet (ami szerintem adatbázis-jellegű), s amivel számtalan alkalmazási terület -- kezdetben legalább az azokhoz vaó kapcsolódás -- lefedhető szeretném én megvalósítani. Ha éppen lekérdezésekről van szó, akkor nem azt mondom hogy a lekérdezések 80%-a azonos, vagy ilyesmi, hanem arról hogy a lekérdezések 80%-a leírható egyetlen lekérdező nyelv (nem feltétéenül SQL) segítségével.
Én egyszer olyat játszottam, hogy fogtam pici cégünk összes adatbázisát, és sokáig jól lelogoltam az őt érintő összes queryt (SQL táblák voltak).
Arra jutottam, hogy a 80-20% szabály egy nagy humbug. Egyszerűen nem igaz. Van, hogy inkább 96-4% szabálynak, van, hogy inkább 50-50% szabálynak. Ez alapvetően két dologtól függ:
- az adatbázis struktúrájától
- az őt érő queryk jellegétől.
Nem tudom, hogy ez a 80-20% szabály honnan jön. Gyanítom, hogy valami elméleti fellegekben ülő okostojás találhatta ki 30 éve, azóta meg mindenki elhiszi - nem azért, mert igaz, hanem azért, mert olyan jól hangzik.
Nem ez az első, és nem is az utolsó babona, amit szoftveres körökben mindennemű ellenőrzés nélkül elhisznek, sőt, iszonyatos erőforrásokat építenek rá csak azért, mert olyan jól hangzik. (Amúgy tényleg jól hangzik, nem tagadom.)
OFF
Szerintem Kartekony arra (az igen csunya) megoldasra gondolt, hogy egy kutya ket rekordot is reprezental, egyszer fel lesz sorolva az apja, egyszer pedig az anyja reven). Ez elvileg megoldhato, csak nagyon csunya, mivel redundans adatokat tartalmaz. (Lasd normalizalatlan adatbazis...)
ON
OFF!
Szerintem egy oszloppal nem oldható meg, mivel általában két szülő van (illetve max 1 hím és 1 nőstény). Egy oszlopban két adatot tárolni viszont nem szerencsés.
ON!
köszike,ilyen megoldások nekem is érthetőek, inkább az a kérdés hogy nincs-e erre problémára valamilyen kidolgozott MÁS adatkezelő motor.
pl ha ebből egy komplett családfát kellene megrajzolni midenkinek 2 szüleje, azoknak is 2-2 tehát elképzelhető h nem 1-2 szintre kiváncsi a felhasználó hanem az összesre. ez algorimizálható csak nem akarjuk feltalálni a megelegvizet.
még 1x thx
hello !
Azt hiszem értem mit akar 'andrisKa' :) és egyetértek a célkitüzéseivel.
Annyit változtatnék az eredeti felvetésen hogy ne adatbázisokban hanem obiektumokban gondolkodjunk.
Egy adatbázist felfoghatunk obiektumok tárházának, sot egyetlen obiektumnak amely más obiektumokat tartalmaz(hat).
Az eredeti felismerés, hogy jó lenne 1 általános adatbázis kliens, most úgy alakul, h. jó lenne 1 általános obiektum
viewer/editor.
Az obiektumok legyenek önleiróak, vagyis tartalmazzak egy standard módon lekérdezheto metainformaciót a szerkezetükrol.
Ez technikailag 1xü probléma, itt a standardizálás jelent gondot.
A nehezebb dolog szemantikát azaz értelmet rendelni az obiektumokhoz.
Pl. 1 ob. tartalmaz egy "array[400,300,3] of byte" tömböt, ha megnézem, az object browser szépen pörgeti a képernyon a
számokat, csak éppen a 400x300-as rgb képet nem látom amit az obiektum tképpen jelent. Ugyanis egy másik uilyen szerkezetü
ob. jelentheti pl. egy tudományos kisérlet mérési adatait, stb. Az adatszerkezetbol nem deritheto ki az obiektum értelme.
Ezt részben meg lehet oldani ha az obiektumok (std. lekérdezheto és futtatható) metódusait tekintem az obiektum
'értelmenek'.
Tfh minden ob. 'életének értelme' egy device vezérlese. Léteznie kell 1 (bovitheto) standardnak amely minden device
osztályhoz egy azonositót rendel, az ob. pedig megmondja h. o milyen device-ot képes vezérelni. Ez lehet pl. képernyo,
hangcsatorna, keyboard, robot, szerszámgép, stb. Ha a felhasználó rendelkezik a megfelelo device-al akkor az obiektum azt
jól megvezéreli. Ekkor már egyértelmü, h. az emlitett tömb képként kell megjelenjen vagy a kisérletet ábrázoló
grafikonként, stb.
Itt egy ujabb és nehezebb standardizálási probléma merül fel ui. definiálni kell a lehetséges device-okat, az általuk
elvégezheto atomi müveleteket (api-t kell definiálni). A tech fejlodes miatt a device-halmaz folyamatosan fog bovulni, új
müveletekre lesznek képesek a régi device-ok, stb. Ezt jól lestandardizálni és a változásokat követni nagyon nehéz.
A szemantika kérdése még igy is nyitott marad. Mi van ha olyan képekre akarok keresni amelyek kutyáját sétáltató
kisgyereket ábrázolnak ? Ehez nem elég az obektumnak azt tudnia h. hogyan rajzolja magát ki a képernyore.
Na itt (egyelore) befejezem; igy is hosszu lett, pedig még folytatnám.
Szerintem ha a kutyakat leiro entitas tablaba beveszel a parent oszlopot, ami for.key a tabla sajat prim.key-ere, akkor minden gondod meg van oldva. (Gondolom le van tarolva a kutya neme, tehat abbol megallapithato a kapcsolat milyensege. Nem kell apa_id, anya-id ! )
Esetleg teljesitmenyi megfontolasokbol lehet, hogy prakikusabb a kulon kapcsolotabla, de szerintem felesleges.
Ez az! Reklamot mindenhova! En is mindjart elkezdem reklamozni kedvenc platformomat (Fujitsu-Siemens BS2000)!
BTW: mitol szabvanyos egy rendszer,ami csak onmagaval kompatibilis?
Páran kezdenek nagyon ráérezni a dolog lényegére, amit elképzelek. Most nem tudok, de holnap jelentkezek s folytathatjuk az elmélkedést.
A kutyagyerekre is elmondom majd a megoldást, tök szimpla. Bár én Oracle alatt ismerem, szerintem MS alatt is menni fog, mert pld. etéren a MS kifejezetten jó.
kedves kóderek, véletlenül találtam ide (közlemények) talán nem off:
hogyan lehet HATÉKONYAN szülő gyermek fa sttúkrákat kódolni, tárolni ?
rábökök egy kutyára mongyuk és látni kéne a családfáját: kik a szülei azok szülei, leszármazottak stb.
van erre valami gyakorlat/bevált cucc ?
lehetőleg m$ alapon :( de minden megoldás érdekel, köszike, lehet magánban is, esetleg URL.
m.
Eccerű: nem ócska PCkben kell gondolkozni, mert az nem erre van kitalálva. Hanem mondjuk IBM AS/400e. Az minden ízében adatbáziskezelésre van tervezve, még az oprencere is úgy működik, teljesen leszabványosított az egész, baromi stabil, gyors, és jó. Ára kb. kétmilliótól ötvenig, de ez azt jelenti, hogy mondjuk 20-03 felhasználóra elég a kétmilliós. Szerintem nem sok.
Szóval nekem a felvetett gondolatról a következő jut eszembe:
Jelenleg ugye van egy akármilyen tipusu (Oracle, Mysql, msql, Microsoft SQL, akármi) public adatbázis valahol, azon egy kész webfelület, és te ezt tudod használni, függetlenül attól, hogy jó e neked éppen, vagy nem. Fix dolog, függsz a meglévő szerkezettől.
Ezzel szemben, ha:
1, adatbázistipus-független egységes lekérdező nyelv létezne.
2, a nyelv elemeként "kötelező elem" lenne a táblák és mezők leírása is a "p_id" jellegű nevek mellett, ami lekérdezhető
3, és mindez az adatszerver fix portján elérhető lenne
4, szabvány adatcsomagot adna vissza
5, nyakonöntve azzal, hogy a különböző oprendszerek adatbázis-jellegű dolgai (file-system tábla, registry) ugyanezen szabvány szellemében készülnének
akkor bármilyen értelmes kérdést tudnál intézni (kellő jogosultságok birtokában) egy adatszerverhez, és arra értelmes választ kapnál anélkül hogy
a, függenél az adatbázis, oprendszer fajtájától
b, fix adatbeviteli és adatlekérdezési képernyőn görcsölnél.
c, a HTML-technológia (szerver lekérdez, legyártja a weblapot, elküldi, böngésző kirajzolja) jelentősen lassítaná a dolgaidat.
d, a megkapott adatcsomagot bármely erre alkalmassá tett programban elemezhetnéd neked tetsző módon.
Erről van itt szó? Mert ha igen, ez valóban igen nagy haladás, és munkagyorsulás lenne.
Az EDI egy ilyen szabványkezdemény. Az anekdotád igaz is lehet, de az nem a szabvány hibája.
Annál is inkább, mivel a "rekord" nem fix mezőszámú és fix hoszzúságú bájtokat tartalmaz.
Pl. tartalmazhatja a következőt
13456:ResetGomb'
34567:resetgomb@index.hu'
Lényeg, hogy a 13456 jelenti azt, hogy ez egy fórumon hülyeségeket beszélő nick-je, a ":" jeleni, hogy innen következik az adat értéke, a "'" jeleni az adat végét. Ugyanígy 34567 jeleni az illető e-mail címét.
A lényeg, hogy ezek a számok egységesek mindenhol.
Az egesz topikbol egy szot se ertek, de eszembe jutott egy anekdota, miszerint az EDI-ben (akarmi is az) minden adatrekordban van egy "ajtok szama" mezo, akarmirol is van szo, mivel az egeszet autogyarak kezdemenyeztek, es ok is egyseges leirast akartam minden lehetseges termekre, de legalabbis az autokra...
"Én a felvetésben arra gondoltam, hogy nem elsősorban az eljárásszabványokat, hanem az adatszabványokat keresi, hiányolja."
Ertem. Adatszabvanyok bizonyos szakmakban leteznek: Amivel en kapcsolatba kerultem, pl: Korhazi, orvosi rendszereknel lattam adat szabvanyokat, illetve legitarsasagoknal is vannak ilyenek. Ezek olyan szabvanyok, amik gyakorlatilag definialjak a kotelezoen definialando tablakat, a fieldek jelenteset (beteg neve,...), es adnak egy protokollt az ilyen jellegu infok eleresere. Nyilvan letezik meg egy csomo ilyen adatszabvany, de teljesen lefedni soha nem lehet a vilagot.
Szemely szerint a keresoprogramok jovojet ugy latom, hogy tovabbra is free text szovegben, de mar bizonyos termeszetes nyelvi elemzeseket hasznalva keresnek majd.
Én a felvetésben arra gondoltam, hogy nem elsősorban az eljárásszabványokat, hanem az adatszabványokat keresi, hiányolja.
Mondjuk belépek egy nyilvános adatbázisba és szeretném megtudni, mi ResetGomb telefonszáma.
Erre jelenleg nincs lehetőség, mert a szerverek nem adnak szabványos választ arra, hogy mit, hol és milyen reprezentációban tárolnak.
Egy WEB kereső megtalálhatja mondjuk egy oldalon a ResetGomb feliratot, de nem tudja eldönteni,hogy az egy természetes személy nickje, vagy egy alkatrészkatalógusban az alkatrész megnevezése valamint, hogy a mellette lévő szám az illető telefonszáma, életkora vagy ára.
"miért nem ilyen okos maga az aprónet"
Erre altalaban ket ok szokott lenni:
1. Mert benak irtak.
2. Mert nincs valos piaci igeny arra, hogy tobbet tudjon.
"Nem lenne egyszerübb magát az adatbázis felületet kivinni a webre??"
Szerintem a middle tier-re szukseg van, legfeljebb elofordulhat, hogy nagyon vekony. De pl. egy banki tranzakcio tipikusan igenyel middle-tier muveleteket is, nem modosithatod a kliensrol az adatbazist. Az apronet azert nem jo pelda, mert meglehetosen primitiv. Akkor mar nezzuk mondjuk legalabb az Amazon.com-ot.
"Azért azt megkérdezném, volt-e már valós feladatokban használni az általatok említett technológiákat, s azt is megkérdezném, hogy TÉNYLEG nem zavar-e titeket, hogy a Webes adatbázis-felületetek ilyen bénák, s ha lehetne sem fecölnek túl sok energiát a használahatóságukba."
Persze, hogy hasznalom valos feladatokban az altalam emlitett technologiakat, E-business cegnel dolgozom, es nem erzem ugy, hogy nem lenne eleg technologiai hatter a fejlesztesekhez. Nem ertem konkretan mi a problemad, milyen rendszer fejleszteset konnyitene meg az altalad elkepelt rendszer. Talan ugy lenne ertelme vitatkozni, hogy mondanal egy feladatot, es en megmondom, hogy milyen mai technologiakkal erdemes megoldani, te pedig elmagyarazod, hogy hogyan lehetne egyszerubben.
A Sun vonalon belul konkretan az EJB-t emelnem ki: (Enterprise Java Beans). Ez egy olyan architektura, ahol vannak az adatbazisszerverek, amikre a Bean-ek vannak deployolva. A technologia RMI-re epul. A 'bean' ek remote interface-i publikusak, tavolrol elerhetoek a BEAN szolgalatatasai. Az adatbazisszerver tamogatja tobbek kozott a tranzakciokezelest, security-t, terheles optimalizalas van benne, stb...
A BEAN-ek kodjaban mar kifejezetten az uzleti logikat kell implementalnod, (Java-ban, objektum orientaltan). (Vannak session BEAN-ek, es Entity BEAN-ek) Ez egy jo architektura sok E-business feladatra, bar ketsegtelen, hogy sok elemet a Microsofttol loptak. Te meg ennel is altalanosabb modellt kepzelsz el? Konkretan milyet?
