Adatbázistervezés - komolyan :)
2006-10-31T20:50:10+01:00
2006-11-04T20:12:15+01:00
2022-07-19T06:52:33+02:00
  • Ez jó volt ! Díjazom !
    Mutasd a teljes hozzászólást!
  • blob-ba taroltak a dvd isokat :)

    Tyrael
    Mutasd a teljes hozzászólást!
  • Mi volt az ?

    Az szörnyű nagy !
    Mit tároltak ott a 120 gigán ?

    Privát vélemény egy autodidaktától :
    Ha ez az Oracle 10g-XE+SQLdeveloper+Jdeveloper biztos tudásával rendelkezel, akkor bizton számíthatsz arra, hogy profinak is nézzenek.
    És ez eddig még mindig open source.
    Mutasd a teljes hozzászólást!
  • "Kezel 4GB-nél nagyobb adatbázist, de sose használják ekkora adatbázisra mert nem arra való..."
    Az én kezem alatt volt egy ~120GB-os mysql adatbázis, nem volt vele gond.
    Mutasd a teljes hozzászólást!
  • A MySQL pl elmegy több processzoros gépen is (egyébként az Ora is) de ugyanugy nem használja ki.
    Kezel 4GB-nél nagyobb adatbázist, de sose használják ekkora adatbázisra mert nem arra való...


    Érdekes, akkor vajon hogy lehet az, hogy a MySql alatt jelenleg kezelt legnagyobb adattömeg úgy 30TB (nem GB!) körül van? Való az nagy adattömeg kezelésére is, persze ahhoz vas is kell!
    Mutasd a teljes hozzászólást!
  • Azért kíváncsi lennék arra a könyvelésre, amibe nem tartoznak bele a banki, a pénztári mozgások és a ki és bemenő számlák.


    Mint mondtam, pont ezek adják a könyvelés fő adatmennyiségét/helyigényét. Miért ne tartoznának bele???
    Mutasd a teljes hozzászólást!
  • Úgy jön ide, hogy leggyakoribb felhasználása az Oraclenek, legalábbis ezen a szinten, (ti. XE verzió) a Java weblapok, webalkalmazások és az ügyviteli szoftverek mögött van.


    Gyorsan hozzáteszem, mielőtt még ebbe is beleköttök, hogy ez a saját, nem reprezentatív felmérésem eredménye, a valósággal való bárminemű egyezés csak a véletlen műve. Készségesen elismerem, hogy az emlétett két kiemelésen kívül bármilyen más adatbáziskezelési feladatok elvégzésére alkalmas az Oracle, azonkívül nem vitatom, hogy egy akármekkora cég könyvelése akármekkora is lehet, a ki és bejövő számlákkal együtt még bármekkora is. Sőt, SQL szerkezetben még akármekkorább és bármekkorább is.

    Azért kíváncsi lennék arra a könyvelésre, amibe nem tartoznak bele a banki, a pénztári mozgások és a ki és bemenő számlák. No de Hajnalkám, ehhez te nem érthetsz.
    Mutasd a teljes hozzászólást!


  • Akinek ez nem elég, az vásorolja meg a teljes változatot, vagy használjon MySQL-t.


    És akinek ez sem elég, az írjon asm+pascalban vagy php-ben sajátot
    Mutasd a teljes hozzászólást!
  • Úgy jön ide, hogy leggyakoribb felhasználása az Oraclenek, legalábbis ezen a szinten, (ti. XE verzió) a Java weblapok, webalkalmazások és az ügyviteli szoftverek mögött van.

    ugy tudom, azert eros korlatozasok vannak benne.
    mintha lenne valami 4 gigas max adatbazismeret, stb.


    Midkettő esetén igen nehéz elérni a korlátokat, tehát ebből a nézőpontból egyáltalán nem erős korlátozásokról van szó. A példával arra akartam utalni, hogy elég nagy cégnek kell lenni ahhoz, hogy az ingyenes verzió ne legyen elég. Ha meg így van, akor már nem tétel a fizetős változat sem.

    Senki nem állította, hogy az ingyenes verzió anyit tud, mint a több milliós teljes.

    Inkabb ugy mondanam, hogy a hozzaszolasodban sehol sem lett emlitve, hogy kevesebbet tud.


    Igazából nekem ezzel volt problémám, úgy érzem, hogy ez már csak fölösleges akadékoskodás. Mintha az egymondatos postban ki kellett volna fejtenem, hogy az ingyenes verzió kevesebbet tud, mint a több milliós. Úgy éreztem, ez nyilvánvaló.

    De hogy legyen nektek igazatok, megismétlem a hozzászólást.


    Van ingyenes verzió az Oracle adatbázisszerverből. Az Oracle 10g XE szabadon használható termelő környezetben is. Ettől persze még nem MySQL kategória. Természetesen az ingyenes verzió közel sem tud annyt, mint a több millióért kapható teljes, erős korlátozás, hogy csak egyetlen processzort tud használni akkor is, ha a gépben többvan. Másik igen jelentős korlátozás, amivel a jelenlévők többsége szinte naponta találkozhat, az adatbázis összmérete nem haladhatja meg a 4GB-ot. További korlátozás, hogy az Oracle taszkjának maximális memóriafelhasználása 1 GB lehet. Ez természetesen oylan súlyos korlátozás, hogy megkérdőjelezi az egész értelmét.

    Álljon itt okulásra egy részlet az Oracle honlapjáról:

    Limitations

    In order to make this release easy to install (e.g., via the standard Windows Installer), configure, and maintain, Oracle has built certain limitations into the product.

    The first limitation is memory-Oracle Database XE can address only 1GB of RAM. But when you consider the relative rarity of machines that offer 1GB of memory (especially in small businesses), this limitation should mainly affect how many users can access the database concurrently and, to a certain degree, how well it will perform when those limits are hit. For most purposes Oracle Database XE will be deployed to a single user desktop or small workgroup server, so 1GB is more than enough.

    The second limit is that XE will only use one CPU. That does not mean that it won't multi-task or that it can only perform a single function at a time. Rather, XE will run on a computer with more than one CPU, it just won't scale up to use those CPUs. For that functionality, you need to purchase Oracle Database Standard Edition or Enterprise Edition. Again, for the uses discussed here, one CPU is more than enough.

    The third limit is that only a single XE database can run on any given computer. The important point here is that you don't need a database for each application you create, as you might for some competing databases. Instead, Oracle uses the concept of schemas to separate applications.

    Finally, a 4GB limit is enforced on disk space-which on its face appears to be serious limitation. However, 4GB is a huge amount of storage for most applications. Sure, compared to a multi-terabyte data warehouse, 4GB seems small-but in reality it's hardly that.

    Consider the included HR sample schema. The maximum row size of the EMPLOYEES table is 144 bytes. Four gigabytes is 4,294,967,296 bytes; 4GB/144 =29,826,162. That means you could store almost 30 million employee records. That's a lot of employees. Even accounting for JOBS, DEPARTMENTS, and the other sample tables, you would not want to store that much data locally. (That's why you pay for an enterprise license.) Oracle Database XE is designed to store only a useful subset of that data.

    As you'll learn in the next section, these limitations can actually work for you, not against you, for everyday DBA tasks.

    További részletek olvashatók itt.

    Hangsúlyozom tehát, senki ne hidje azt, hogy az Oracle 10g XE ingyenessége ellenére ugyan olyan teljes értékű, mint az eredeti verzió. Inkább csak játékra, demóra, ismerkedésre jó, arra is korlátozottan. Akinek ez nem elég, az vásorolja meg a teljes változatot, vagy használjon MySQL-t.

    Remélem így már nem félreérthető a hozzászólásom, mindenki megnyugodott.
    Mutasd a teljes hozzászólást!
  • Csak jelzem, hogy az Oracle oldalarol INGYEN letoltheto az sqldeveloper, ami csilivili meg minden...
    Egyebkent valoban korlatos, mint minden ingyenes program.
    Csak a MySQL azért korlátos mert még nem fejlesztették bele az adott funkciót, az Ora, meg a MSSQLExp meg azért korlátos, mert kivették belőle :)
    A MySQL pl elmegy több processzoros gépen is (egyébként az Ora is) de ugyanugy nem használja ki.
    Kezel 4GB-nél nagyobb adatbázist, de sose használják ekkora adatbázisra mert nem arra való...
    Különben meg a bölcs orosz mondas szerint:
    "szuvenyiri nyihaha, nye kukucski protku".




    Mutasd a teljes hozzászólást!
  • Egy kb. 100 alkalmazottat foglalkoztaó cég éves könyvelése is elfér egyetlen floppyn


    Mondjuk egy cég könyvelésében (méretileg) csak a töredék a bér, ezért nem is értem hogy jön ide az alkalmazottak száma?? A banki, pénztári mozgások, bejövő-kimenő számlák, amik a helyet eszik pedig kötve hiszem, hogy egy floppyra felférnének egy közepes méretű cégnél. (Főleg olyan tárolási stuktúrában, amit az SQL szerverek, pl Ora használ)

    Ezek azok a tuti áruló jelek, amik a lamer lamerságára utalnak.


    Ezt te írtad. (bocs, de idekívánkozott ez az idézet....)


    Amúgy nem értem miért okoskodsz Tyrael-el szemben, ő csak hozzátette az Oracle XE korlátait és semmi több. Nem beszélt arról, hogy így már gagyi lenne, sőt arról sem beszélt, hogy egy átlagos cégnek/szájtnak ez tuti kevés. Ezek csak a te feltételezéseid.
    Mutasd a teljes hozzászólást!
  • hó hó gyerekek, itt nehogy összevesszetek, mert a másik röviden írta le amit akart, és nem egy 1000 oldalas esszében járta körül a témát
    Mutasd a teljes hozzászólást!
  • nem, nem tudna tobbet, csak tudhatna, ha adnek hozza supportot, meg miagymast, amit felsoroltal.
    Kylix is befuccsolt, pedig nem open source volt, aztan kenheted a hajadra a supportot, hiaba csengettel erte vagyonokat.
    nem akarok megint open source vitat, de ami olcsobb, az nem feltetlenul jobb, es ami jo, az nem feltetlenul draga.

    sehol nem irtam, hogy XE ne lenne eleg barmire, sot, pont az ellenkezojet irtam, de ha mar azt irtad, hogy oracle-bol is van ingyenes, akkor fontosnak ereztem megemliteni, hogy miben tud kevesebbet, milyen limitek vannak benne.

    ha jol latom, a hozzaszolasod tobbi resze nem konkretan nekem szol, ezert azt nem kommentalom.

    Tyrael
    Mutasd a teljes hozzászólást!
  • Igen többet tudna. Minimum a hivatásos supporttal. De még inkább a mellécsomagolt szoftverekkel, amik vagy jobbak, mint az opensource, vagy ha azok is, akkor sem kell egyenként összevadásznia netről és az adott disztribhez hozzáfordítani, mert már megcsinálták neked előre azért a plusz pénzért.

    Te kötöttél belém, nyilvánvaló hulyeség miatt, ne csodálkozz. Amúgy jellemző hozzáállás, ha az Oracle ingyenes szervere nem kezel több procit, meg 4 GB-nál nagyobb adatbázist, akkor már nem is alkalmas arra, hogy az egyprocesszoros, 1GB rammal megáldott gépen egy kisebb, vagy közepes méretű szájt, esetleg irodai program adatbázisa legyen. Követeljük, hogy a teljes változatot adják ingyen. Ha nem teljesítik ezen követelésünket, bosszúból Access-t fogunk használni. Uff.

    Mind az Oracle XE, mint az MS SQL Express korlátozása nagyságrendekkel az átlagos használati igény felett van, mégis mindenütt, ha felmerülnek ezek, mint a MySQL vagy más opensource alternatívái, azonnal azzal jön mindenki, hogy de ezek korlátozott verziók. Ezekhez nincs vizuális csillivilli reportgenerátor és uml adatbázistervező bizbasz. Ja, mert az opensourcékhoz van. Meg nem tudnak az otthoni gépen akkora adatbázist kezelni, ami egy jól menő belvárosi könyvelő cég 10 éves könyvelési adatbázisa. (Egy kb. 100 alkalmazottat foglalkoztaó cég éves könyvelése is elfér egyetlen floppyn)

    Mint az egyszeri tizenéves, aki nulla tudással eldönti, hogy mától programozó lesz és neki azonnal a Visual Studio Team Server kell tanulni, mert mindenfél lebutított vacakkal nem tudja ám a hellowordot megírni.

    Ezek azok a tuti áruló jelek, amik a lamer lamerságára utalnak.
    Mutasd a teljes hozzászólást!
  • ha penzert arulnam neked a linux kernelt, akkor az mar egybol tobbet tudna, mint az ingyenes? :)
    amugy meg nem ertem mit veszekszel velem, nem mondtam hulyeseget, ne vitazzunk mar ezen.

    Tyrael
    Mutasd a teljes hozzászólást!
  • Gondoltam mindenki számára nyilvánvaló, hogy ha egy cégnek van a szoftveréből egy változata ingyen és egy másik x millióért, akkor az ingyenes kevesebbet tud, mint az x milliós. De lehet, ez csak nekem az.
    Mutasd a teljes hozzászólást!
  • De nekem csak egy nevem van, nincs más adat hozzá, de végül is lehet később kellhet más adat is....
    Mutasd a teljes hozzászólást!
  • Én minden ilyen nagyobbacska rendszerben csinálok egy Persons - vagy valami hasonló nevű - táblát.
    Ide mehet egy ID és egy csomó adat (név,email címek, levelezési cím, cég, telefonok, stb).
    Minden olyan helyen ahol személyek kellenek (ügyvezető, kapcsolattartó, oktató, sőt: felhasználók stb) csak az id-t teszem be a tábla megfelelő mezőjébe és hivatkozok rá.

    (hasonlóan járok el az SQL-ben tárolt képekkel és bináris adatokkal is: akárhány helyen kell is kép az mindig egy közös táblában van)
    Mutasd a teljes hozzászólást!
  • Sok különböző szöveges adat tárolása a cél, de ezek olyanok, h nem kell őket indexelni. Eddig két helyen van redundancia, de azok a táblák az idő folyamán beállnak majd egy fix méretre (100-200 rekord). Pl: cégtulajdonosok neveit nem "szokás" külön táblába rakni, hiába lehet az emberünknek több cége, ha a nevén kívül más adatot nem tárolunk róla, és nem kell a tulajdonos alapján megkülönböztetni a cégeket.

    de a külső kulcsokat, mint ahogy a progi is akarta, szerintem majd kell indexelni, mivel sok SELECT csoportosító feltételében lesznek benne
    Mutasd a teljes hozzászólást!
  • Senki nem állította, hogy az ingyenes verzió anyit tud, mint a több milliós teljes.


    Inkabb ugy mondanam, hogy a hozzaszolasodban sehol sem lett emlitve, hogy kevesebbet tud.

    Abszolut egyetertek veled, webes kornyezetben a limiteket szinte eszre sem lehet venni.

    Ha csak annyit odabiggyesztettel volna a mondatod vegere, hogy persze az ingyenes verzioban vannak korlatozasok, mar nem is irom, amit irtam, csak ugy ereztem, hogy a teljesseg kedveert meg kell emliteni.

    Amugy tetszik nekem is, gondolkodom rajta, hogy ki kene probalni.

    Tyrael
    Mutasd a teljes hozzászólást!
  • 1) Egyetértek
    2) Ezzel a problémával még nem találkoztam (nem futottam bele), de nem kizárt. A tranzakciók felelőtlen használata azonban e nélkül isokozhat DL-t.
    3) Persze, hisz - főleg gyakran változó adatoknál - az adatok eloszlása gyakran változik. Egy rossz statisztikából hozottrossz döntés pedig rengeteget ronthat avégrehajtási terven.
    4) Nem hiszem, hogy rosszat mondtak :).
    MS SQL is képes rá, csak ez ugye ritka eset mint a fehér holló, hiszen nagyon ritkán van szökség csak 2-3 mezős listákra ha >10 mezőből áll a tábla ennél nagyobb indexet csinálni (főleg ha karakteres mezők is vannak benne) már felelőtlenség.
    El tudok képzelni pl. egy olyan esetet amikor egy listában megjelenítem az alap adatokat, majd kijelölve a részleteket is. Ha viszont a usernek szüksége van a döntéshez egy varchar(100) mezőre is (pl. egy név) akkor már elgondolkodtató, hogy egy pár százezres táblára rárakjak-e egy ilyen összetett indexet.
    Mutasd a teljes hozzászólást!
  • Néhány megjegyzés:
    1; Indexek száma, tőlem okosabb emberkék tuning tanfolyamon (oracle), azt mondták, hogy két-három indexnél több többet ront, mint használ, ezekre voltak mérések és esettanulmányok is. Természetesen PK használata mindig javasolt, jól kiválasztott indexekkel nagyságrendi javulás és rosszak esetén romlás is elérhető...
    2; Az MSSQL kezét eltörném a clustered index miatt, igaz ez főképpen ott jelent hátrányt ahol a bevitelek és a törlések aránya közel azonos. Ugyanis a clustered index fizikailag rendezi az adatokat, ami szép kis deadlock-okat okozhat sok felhasználó esetén főleg ha tranzakciókat is használsz... Ha csak bővül a tábla akkor nem okoz igazán galibát.
    3; Minden adatbáziskezelő esetén igaz, hogy a query plan csak az adott időpillanatban igaz, a megfelelő gyakoriságú statisztikafrissítés csodákra képes... Nem beszélve egy export-import páros tömörítési és gyorsítási képességeiről.
    4; Az indexek tervezése esetén figyelembe kell venni, az adatmennyiséget, és a lekérdezéseket. Ezekből kell olyan kompromisszumos megoldást faragni, hogy mindenki jól járjon. Egy öt soros táblára felesleges ezerféle indexet készíetni, míg egy 20-100 millió sort tartalmazó tábla estén pedig nagyon is meg kell fontolni, hogy mi kerüljön be az indexbe. A többi pedig valahol a kettő között van. Az oracle például képes arra, ha a lekérdezésben szereplő mezők mind megtalálhatók az indexben, nem is fordul a táblához (ha a tanfolyamon hazudtak, most én is hazudok), csak arra kell ügyelni, hogy a jól válogassuk meg ezeket a mezőket.
    Mutasd a teljes hozzászólást!
  • Senki nem állította, hogy az ingyenes verzió anyit tud, mint a több milliós teljes. De úgy vélem, jó sokáig elég lesz a 4GB, feltéve, hogy nem akarja valaki a fájlokat is abban tárolni. Nálunk a publikus hoszt gépne nincs 4GB a MySQL összméret, pedig 50+ szájt fut rajta. Köztük pár webshop a számlázásával együtt. Egy dedikált gépen pláne elégnek kell lennie. Sőt, ha kétprocis a gép, akkor az egyiken futhat az Oracle, a másikon a rendszer és a webszerver, ki lehet használni a dupla procit. Mert az egy procis limit azt jelenti, hogy az Oracle taszk nem futhat csak egyetlen procin, de lehet a gépben több és más taszkok használhatják.

    Aki meg kinövi, az majd megveszi a teljes verziót, akkor már gondolom nem lesz gond a kifizetésével.

    Megjegyzem, az MS SQL 2005 Express is hasolnó limitációval rendelkezik.
    Mutasd a teljes hozzászólást!
  • Komolyabb rdbms-ek (ha jól tudom, már a MySQL is) index statisztikákat használ annak eldöntésére, hogy egy lekérdezésben használja-e az indexet vagy sem.
    Ez látványosan modellezhető az SQL Query Analyzer segítségével (MS SQL Server egyik toolja) aminél a végrehajtási tervben adott feltételnél "index scan" másnál pedig "table scan" van (annak ellenére, hogy az indexelt mező szerepel a feltételben).
    Ennek oka, hogy az indexek használata is erőforrást igényel és nem mindig éri meg.

    Tehát egy indexxel nem feltétlenül gyorsítasz a lekérdezéseken, viszont biztosan lassítasz a módosító utasításokon.

    A PK automatikusan (clustered) index. Alap, hogy a FK mezőket indexeljük. Innentől fogva viszont az adatok eloszlása az, ami meghatározza, hogy mely mezőkre kell index és melyekre felesleges. Ez pedig csak akkor derül ki, ha
    - vagy nagyon pontosan tudod előre milyen adatok kerlnek azadatbázisba
    - vagy egy próbaidőszak után megméred.

    Mivel indexeket bármikor létre lehet hozni így én ezzel nem foglalkoznék a helyedben a tervezés időszakában. Az ügyfél el fogja fogadni, hogy x hónap múlva visszatérsz és optimalizálsz a valós adatok alapján.
    Mutasd a teljes hozzászólást!
  • a memoriakorlat meglepett.. nekem panaszkodott, hogy 512MB RAM + ugyanennyi swap keves neki, es kert meg 1GB swap-ot :)

    szoval duplaannyi memoriara van szukseg a futtatasahoz, mint amennyit hajlando hasznalni..

    plusz korlatozas, hogy az xe-hez nem jar az oracle-n megszokott grafikus kattingatos felulet, helyette csinaltak javascript alapu webeset..
    ennek a webes feluletnek plusz erdekessege, hogy csak IE alol mukodokepes, firefox es opera alatt is hasznalhatatlan.. ez a linuxos xe verzio eseten is igy van, szoval ahhoz, hogy egy linux serveren levo adatbazist adminisztralj, mindenkepp win-re van szukseg.. (solarisra forditott IE-t nem probaltam, az igaz.. de az csak 5-os verzioig letezett)
    erdekes tervezoi dontes :) (mondjuk igy konnyebb tavolrol adminisztralni, nem kell hozza a speci programja)
    az sql plus az egyeduli amit adnak hozza, es kulon progi..
    telepiteni viszont tenyleg egyszeru, azt elismerem..

    TomSoft: mennyi string-jellegu adatot hasznalsz? mennyire ternek el ezek egymastol?
    gondolom a gyakran hasznaltakat kulonszeded masik tablaba, es onnan kapcsolod hozza.. (elegge alap, de temaba vag..)
    Mutasd a teljes hozzászólást!
  • ugy tudom, azert eros korlatozasok vannak benne.
    mintha lenne valami 4 gigas max adatbazismeret, stb.

    Limitations

    In order to make this release easy to install (e.g., via the standard Windows Installer), configure, and maintain, Oracle has built certain limitations into the product.

    The first limitation is memory-Oracle Database XE can address only 1GB of RAM. But when you consider the relative rarity of machines that offer 1GB of memory (especially in small businesses), this limitation should mainly affect how many users can access the database concurrently and, to a certain degree, how well it will perform when those limits are hit. For most purposes Oracle Database XE will be deployed to a single user desktop or small workgroup server, so 1GB is more than enough.

    The second limit is that XE will only use one CPU. That does not mean that it won't multi-task or that it can only perform a single function at a time. Rather, XE will run on a computer with more than one CPU, it just won't scale up to use those CPUs. For that functionality, you need to purchase Oracle Database Standard Edition or Enterprise Edition. Again, for the uses discussed here, one CPU is more than enough.

    The third limit is that only a single XE database can run on any given computer. The important point here is that you don't need a database for each application you create, as you might for some competing databases. Instead, Oracle uses the concept of schemas to separate applications.

    Finally, a 4GB limit is enforced on disk space-which on its face appears to be serious limitation. However, 4GB is a huge amount of storage for most applications. Sure, compared to a multi-terabyte data warehouse, 4GB seems small-but in reality it's hardly that.

    Consider the included HR sample schema. The maximum row size of the EMPLOYEES table is 144 bytes. Four gigabytes is 4,294,967,296 bytes; 4GB/144 =29,826,162. That means you could store almost 30 million employee records. That's a lot of employees. Even accounting for JOBS, DEPARTMENTS, and the other sample tables, you would not want to store that much data locally. (That's why you pay for an enterprise license.) Oracle Database XE is designed to store only a useful subset of that data.

    As you'll learn in the next section, these limitations can actually work for you, not against you, for everyday DBA tasks.

    forras

    Tyrael
    Mutasd a teljes hozzászólást!
  • jelentősen több lesz a lekérdezés mint az INSERT, UPDATE, DELETE...

    Egyenlőre még csak tervezés alatt van az adatbázis, szal még egy árva SELECT-tet sem csináltam hozzá, még jóformán csak "papíron" létezik :)

    Szal azt mondjátok h utólag teszteljem ,h h működik gyorsabban?
    Mutasd a teljes hozzászólást!
  • folyt:

    Nekem van olyan táblám, amiben egy bizonyos lekérdezés miatt nem használok indexet. Emiatt minden más lekérdezés (ami szintén használja a táblát) lassabban fut le, de muszáj volt, mert az az egy lekérdezés fontos volt a cégnek, és gyakrabban használták mint a többit. Valamint annál nagyon brutális eltérés volt az indexelt, és index nélküli tábla között. (fél perc vs 3 perc) Míg a többi (egyszerűbb) lekérdezésnél a nem_indexelés csak 1-2 másodperces különbséget jelentett.


    Mutasd a teljes hozzászólást!
  • Van ingyenes verzió az Oracle adatbázisszerverből. Az Oracle 10g XE szabadon használható termelő környezetben is. Ettől persze még nem MySQL kategória.
    Mutasd a teljes hozzászólást!
  • az indexelés gyorsíthatja is a lekérdezéseidet, de lassíthatja is. KI kell próbálni jó sok teszt-adattal.

    Indexelni utólag is tudod a mezőket sőt, kapcsolgathatod is kódból. (legalábbis accessben)

    Példul ha nagyobb adatmennyiséget akarsz INSERT-elni (hozzáfűző lekérdezéssel) egy táblába, akkor nem árt kikapcsolni. Aztán a folyamat végén visszakapcsolod.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd