>>>>>>>>>>> Elvagyok a gyenge képességű programokkal, és megpróbálok a magam módján hozzátenni annyit, hogy jobban működjön a végeredmény. Szóval felesleges szidni az OWB-t, jól el lehet azzal is buherászni. Majd jön hozzá peccs. :) >>>>>>>>>>>y
A cikk mérnökének egyik mondatával reflektálnék => ' Végül is igazad van. De ez a te igazad, nem az enyém.'
;)
Kétségtelenül reális álláspont, mindannyian próbálunk így-úgy megfelelni neki. Senki nem akarja a világot megváltani...Azt azonban a magam részéről gondolom, ha valami romlás; azt azért legalább minimálisan vegyük már észre (még ha elgondolkodni rajta nem is érünk rá), és ne állítsuk be természetesnek.
Egyébként gazdasági alapozású érveléssel is levezethető talán, hogy az idézet gondolatmenet lehet káros is.
Nem mindegy, hogy valaki beruház egy windows registry optimalizálóba, és kockáztat minden egyes futtatásával, vagy eleve nem hagyja teleszemetelni és sose lesz neki szüksége 'vérfrissítő reinstallra'. El lehet gondolkodni melyik eljárás szimpatikusabb és olcsóbb a buherálást illetően (így kicsiben)
A "buherászásnak" és "peccseknek" is van ám nemkicsi infrastrukturális meg humán költsége (belső tesztelés, időtényező, tévedési lehetőség miegymás), ami ráadásul mindenkinél jelentkezik kivéve a sz*rt szállító fejlesztőnél nem, ugye... ;) Az ilyen lavírozás is izgalmas szellemi kihívás (lehet, legalábbis egy ideig), de nem lenne inkább kifizetődöbb értelmes problémákon dolgozni helyette?
PS: Egyébként már többen írtátok ezt a 100%-os termék-csinálás problémát. - Én egyrészt megértőbb vagyok, mert azt gondolom, létezik mai is olyan feladat (pl.: neurális hálós, fuzzy rendszeres adatbányászati technológiák), ahol a jelenlegi tudásunkkal majdhogynem lehetetlen tényleg jót csinálni. (Spéci versenyek témája, hogy egyáltalán mit és mennyire lehet általánosítani, nem hogy azt még implementálni is egy kereskedelmi vagy vagy free szoftverben...) - Másrészt nem győzöm hangsúlyozni; szerintem vannak fokozatok, van különbség bug és bug között illetve bugosság és bugosság között. - Harmadrészt nem mindegy, hogy valami eleve koncepcionálisan sz*r, vagy pusztn csak egy nem megfelelő release került ki a gyártó kezéből, amit másnap azonnal orvosolni lehet (bocs mindenkitől, de szerintem a Windows Vista _koncepcionálisan_ problémahalmaz, de mondhatnám a Borland Delphi 200* Studiót is, de ez innentől már tényleg off /különben is saját szubjektív vélemény/) - Negyedrészt szerintem igen is vannak szoftverek, nem is kevés, ami emberi léptéküek (amit vállalnak azt tudják) és minőségük aszimptotikusan konvergál a 100%-hoz.
Elnézést az offért, csak szeretném megvilágítani kicsit a másik oldalt is. Lehetne csinálni 100%-osan működő termékeket, de mégsem csinálnak és ennek ugye a pénz az oka. Minden cég, aki szoftverfejlesztésre adja a fejét, épp csak annyit tesz bele a szoftverébe, hogy a megefelelő piaci részesedést ki tudja hasítani. Néha még annyit sem, de olyankor segít a marketing. A másik oldalon pedig, amikor egy cég megvesz egy terméket, el sem várja hogy az 100%-osan működjön. Miért is kellene? Ez nem űrhajó, vagy atomtengeralattjáró. Ezen lehet keseregni, de szerintem felesleges. Legalábbis én letettem róla egy ideje. Elvagyok a gyenge képességű programokkal, és megpróbálok a magam módján hozzátenni annyit, hogy jobban működjön a végeredmény. Szóval felesleges szidni az OWB-t, jól el lehet azzal is buherászni. Majd jön hozzá peccs. :)
>...az összes üzletileg sikeres sziftvercégre is kiterjeszthető. A mamutokra legalábbis biztosabban. De az arányok azért kisebb-nagyobb mértékben eltérhetnek cégek vonatkozásában is, termékek vonatkozásában is. Az OWB mondjuk kiugróan negatív példa (legalábbis számomra)
Jó ötlet mindig is volt/van/lesz, IT vonalon. De a pénzügyi, marketing, kapcsolati meg a szakmai tőkék közül a legutóbbi valahogy egyre inkább egyre vészesebben szorul háttérbe , ahogy én érzékelem.
Nem véletlen, ahogy szinte azonnal felvásárlódik egy jó ötletből készült termék mögötti cég valami nagy hal által (a koncentrálódás jegyében). Illetve nem véletlen az a sok irányból erösődő tapasztalat sem, hogy a "nagy hal" mit képes néha művelni 'termékfejlesztés' címén (a tulajdonában lévő termékével).
Kozben megoldodott. Azt hiszem azert nem ment mert futott az AVG center de leallitottam es elindult. Gondolom a tuzfalak miatt nem indult, de most mar megy :)
Lenne egy kerdesem, nekem Oracle 10g-m van, es amikor a start menubol el akarom inditani a "GO TO DATABASE HOMPAGE" -t akko az explorer nem tudja megnyitani az oldalt, milyn beallitasokkal van gond?
Az írás viszont találó és - ezért sajnos, hogy - szomorú hangvételű. Az OWB-re való utalás - szintén sajnos - erősen általánosítható: igazából ma már gyakorlatilag az összes üzletileg sikeres sziftvercégre is kiterjeszthető. Próbáltam tárgyilagos és részletekbe menő összehasonlítást találni a különféle adatbázismotorok közt. Nekem nem sikerült :( Amiket találtam, jellemzően arról szóltak, hogy az adott termék mennyire jó és a többiek mennyire rosszak - minden szempont szerint, kivétel nélkül. Nem nagyon hihető...
Hmmm, az lehet. Én csak hozzáadni próbáltam. Nálunk az dívik csak szerencsére. Érdekes megjegyezni, hogy attól, hogy a táblán most az van beállítva, hogy NOCOMPRESS, attól még lehetnek benne korábbról tömörített blokkok, és akkor (helyesen) az add column ugyanúgy problémázott (9i-ben). Szóval ilyenkor kap egy szép "move nocompress"-t, hozzáadjuk az oszlopot, aztán "move compress". Partícionált táblánál minden partíciót néz (szintén helyes), úgyhogy 10g elött biztos nem fogjuk kipróbálni az 1.5 TB-os OLTP rendszerünkben a 30-100GB-os táblák régi partícióira - ennyi állásidőnk nincsen, főleg nem egy amúgy 1perces műveletre.
Mi hiba, mi nem.... A 9i2 doksinban az ADD COLUMN-nál nincs leírva, hogy compressed táblán nem lehet. 10g2-es doksiban meg "aszondják", hogy default értékkel nem lehet :) Tulajdonképp írhatták volna megoldásnak, hogy a doksi hibás. Esetleg ki is javíthatnák a doksit. És akár a compressről szóló szép szövegekben ("használjátok, mer' az jó"), meg is lehetne említeni a hátrányok közt.
Az a bug szerintem sajnos csak arra vonatkozik, hogy a hibaüzenet nem helyes, mert félrevezető szöveget mutat. Például "ORA-12996: cannot drop system-generated virtual column" jön a helyes "ORA-39726: unsupported add/drop column operation on compressed tables" üzenet helyett.
Még 10gR2-ben sem tudsz tömörített táblából oszlopot eldobni.
BTW, nem véletlen ajánlottam korábban OWB-mappingek tanulmányozását, forall és/vagy táblafüggvények-re bőven tudsz találni példát.... nyílván a neten is, de mivel az OWB ízig-vérig Oracle-termék ("nem egy benyelt kishal"), azt gondolom érdemes lehet böngészni mire jutott az évek során a témában... ;) Persze nem akarlak rábeszélni, félre ne érts!
>>"A repository-technológia (designer, discoverer, owb stb.), alapvetően elhibázott koncepció" >Pontosan mi a bajod a repository koncepcióval? Mi lenne a jó helyette?
Meglehet, hogy virtuális népharagot fog kiváltani a hozzászólásom... ;)
Mivel lesznek szubjektiv elemek is ezért kezdetnek pár tény:
1. Windows Vista & "adatbázisszerű" WinFS napjainkban is zajló pro-kontra története http://index.hu/tech/blog/2007/06/26/halal_a_windows_longhornra/ http://longhorn-reloaded.org/
2. Sourcecode Version System -> filerendszer kontra DB szervezésű tárolása Amikor foglalkoztam a kérdéssel behatóbban, egy-két szoftvert találtam, ami a DB-t (is) támogatta
3. Firefox & sqlite ami mostanság van napirenden
Mi a közös (szerintem) az Oracle Designer, OWB-t, stb is immár bevonva, repository technológia szemszögéből...
- Mikró környezet (nem sok felhasználó, nem egeket ostromló párhuzamos feldolgozás) - Speciálisabb feladatok ahhoz képest, amiben a relációs adatbázis nagyon jó eszköz - Továbbra is létezik tulajdonképpen 'ekvivalens' alternatíva (pl.: filerendszer) - Lehet összevetni egy (automatikus!) filerendszer-s migrálást a db-migrálással.... Sokkal-sokkal nehezebb az utóbbi, nemvéletlen, hogy annyit hibázott az Oracle - Minden DB-környezet drágább, sőt talán a legdrágább a teljes életciklust tekintve - Nehéz repo-tervezéskor relációs strukturát tervezni és azt időnyomás alatt állandóan módosítgatni - Tervezési-komplexitás egy határon túl nő, nemvéletlen az OO és XML típusú eltérés a 100% pure relációs adatmodelltől. A DW-k tervezési módszertanáról már ne is beszélve... ;) Kézenfekvő kedvenc példám: nem mindegy, hogy egy mező azért null mert megengedi a definició, vagy azért, mert hiba történt...
Zárszóként, én nagyon sok eszközt kipróbáltam, hogyan tudnám leghatékonyabban "átlátni" irdatlan levéladatbázisomat (de mondhatnám a favorites-okat is). Azonkívül, hogy maradéktalanul szimpatikusat egyet sem találtam (azaz meg kéne írni) a Total Commanderes file-rendszeres (környezetfüggő!) kezelésnél hatékonyabbat nem találtam. Ismerjük az "egymiliárd légy nem tévedhet" effektust ;), de nem véletlen, hogy ennyi akadály van a valós életben is. Nem vitás, hogy van előnye is az egész repo-témának (pl.: regexp-es relációs keresés, ahogy szó is volt róla), de ahogy mondtam költsége is van a dolognak...
Így már teljesen OK! :o) Abszolút valós szitu amit írsz, én is számtalan ilyenben voltam... Ami meg a TPC-H-t illeti, na ez az amiről beszéltem... ;)
A history-kezelésnél szerintem alapelv, hogy minél régebbi az adat benne, annál olcsóbb (igaz lassabb elérésű) háttértáron a helye. Ez bőven lehet a compress tárgya, majd az élet eldönti, hogy életképes új alternatíva-e.
sarki lény, KingFishR, az lehet, verziót nem említettél, s.l., csak RAC-ot, bár én sem kérdeztem rá. Nekünk RAC-ból csak 10g van, 9i RAC-cal nem is dolgoztam korábban sem, így nekem ez volt a természetes, és ahogy a doksijában te is olvasod, ott így is működik. Pontosabb hibameghatározást és körülményleírást ezentúl. ;-)
Az elvileg már a 10g-ben is ki van javítva, nemtom miért new feature. Azért az vicces, hogy elég régóta bugnumber (2421054) van hozzárendelve, hogy "nem megy az add column compressált táblán", és volt pof*juk azt írni, hogy "10g-ben javítva". Esetleg kaphatnánk 9i2-re egy szép kis patchet, nem??? Lehet, hogy az a new feature, hogy mostmár tényleg menni fog??? ;-)
9i RAC-ban a redo logoknál nem csak a group meg a member változik, hanem a thread is. Minden instance-nak saját redo thread-je van. Minden instance saját magának archivál, a többiekét nem bántja. Így minden instance-nak a redo és az archlog lokálisan keletkezik. Ezért is érdekes munka pl. egy szép nagy helyreállítás...
Ezzel nincs is semmi bajom: csak fejlődjünk-fejlődjünk :)
Hogy nem kerestél elég pontosan: inkább azt mondanám, hogy én nem neveztem meg a featuret pontosan.
A "Tablespace compression" kifejezéssel csak annyi a bajom, hogy nem az jut eszembe róla, amit csinál. A "Data segment compressionnál" is azért nem jutott eszembe a pontos kifejezés, mert ez a tömörítés dolog az Oracle-nél blokkszintű. Ennek megvannak az előnyei és a hátrányai. Pl. a DB2-es tömörítés 1 db 75-100KB-os directory-t (vagy mi a neve) használ az egész táblára, ezért ott tényleg táblaszintű. Ennek köszönheti, hogy sok, az egész táblára kiterjedő érték esetén jobban tömörít, mint az Oracle, mivel nem kell minden blokkban megismételnie ezeket az értékeket. Viszont minden blokkba insertálás egy 75-100KB-os dictionaryben való túrkálást eredményez, ami mindenképp lassabb, mint egy max néhány KB-os dictionaryben való túrkálás. Ráadásul, ha a rekordok valamiért úgy helyezkednek el, hogy azonos értékek jól egymás mellett legyenek (egy blokkban), akkor akár relatív sok különböző érték is jól tömörítve tárolható az oracle-féle megoldásban. Az más kérdés, hogy erre ügyelni kell. Annyi ilyen feature van már, hogy örülök, ha a dolog lényege eszembe jut, nemhogy a marketing neve. :-) Főleg, ha folyamatosan változtatják, mimnt pl. a HTMLDB-ét :)
A DB2-őt én sem ismerem nagyon, csak a tömörítgetés kapcsán találtam rá egy ezzel kapcsolatos fórumra. A TPC-H (?) adatbázisán pedig mindkét cég publikált már tömörítési arányokat, és a DB2 magasan vezet. Mindazonáltal nekem úgy tűnik a leírásokból, hogy a dictionary-t csak reorgnál tartja karban, tehát az új értékeket nem fogja tudni tömöríteni. Persze erről nincs explicit infóm, úgyhogy akár téves is lehet a következtetésem. Ebből is látszik, hogy a szkepticizmus mindig rulez ilyen marketingszagú dolgoknál. ;-)
Na éhenhalni én sem akarok. ;-) Csak egy reorg miatt szükségem volt a compressre, az üzlet meg örült neki nagyon, hogy most akkor nem kell diszket venni. Csak közben 1 hónap alatt már 100GB-ot vesztettünk a megnyert TB-ból :( Félreértés ne essék, én tudtam, hogy fogunk veszíteni, meg nem is ígértünk hosszútávra ekkora nyereséget, csak ráharaptak :) Ezért keresek minnél tisztább, és a feldolgozás összidejét nem növelő megoldást a compress előnyeinek megőrzésére.
Nálunk az OLTP-ben is szép nagyok a history táblák, ott is szívesen kipróbálnám az 1-2 hónapnál régebbi adatokra a compresst, ha már partíciónként is lehet tömöríteni.
