- This topic has 72 hozzászólás, 16 résztvevő, and was last updated 17 years, 4 months telt el by
.
-
Bejegyzés
-
cskiraly wrote:Sziasztok!
Tudna valaki segíteni, hogy az alábbi MySQL utasításnal mi lenne a helyes szintaxisa?
Pontosabban az evfolyam sornak a megszorítás a hibás.create table hallgato(
neptunkod varchar(6) primary key,
nev varchar(30),
evfolyam number(1) check(in(1,2,3,4,5,6)),
szuldat date,
lakhely varchar(30),
szak varchar(20)
)???
Miaz, hogy check – in ???
Ez nem MSSQL
A MySQL az ENUM típust támogatja ijen esetben.
Vagy így használható ez a módszer:Code:create table hallgato(
neptunkod varchar(6) primary key,
nev varchar(30),
evfolyam int(1) check(1,2,3,4,5,6),
szuldat date,
lakhely varchar(30),
szak varchar(20)
);De egy igazi programban így csinálnám:
Code:create table hallgato(
neptunkod varchar(6) not null primary key,
nev varchar(30),
evfolyam int(1) check(1,2,3,4,5,6),
szuldat date,
lakhely varchar(30),
szak varchar(20)
) ENIGINE=MyISAM DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;Köszi Kayapo. Tudom, hogy triviális jellegû volt a kérdés ezért sajnálom, ha valakit esetleg zavart, de a jegyzeteim alapján nem igazán boldogulta. Mellesleg ezért adatam témacímnek a mysql kezdõt. Bár a nagyon kezdõ jobb választás lett volna:)))
Akkor én is kérdeznék egy triviálisat:-)
Milyen esetekben lényeges, hogy melyik engine-t használom (pl. MyISAM vagy InnoDB)? Ha jól tudom az elõbbi pl. korábban nem támogatta a foreign key-eket….Ma mi a helyzet, ökölszabályszerûen melyiket mikor célszerû alkalmazni (a többi engine is érdekes lehet)?Amikor én nézelõdtem SQL server után a MySQL InnoDB -je nagyon lassú és helyigényes volt.
A foreign kulcsokat akkor használod ha a referencia integritás ellenörzését és betartását a szerverre bízod, ha nincsenek ilyenek akkor ezt a programodnak kell biztosítani, azaz relációs kapcsolatokat neked kell figyelned (pl. nem lehet olyan gyerek rekord ami nemlétezõ szülõre hivatkozna).tovis!
InnoDB és lassú Hmm…
??? Mi neked az elég gyors? Az InnoDB a kategóriája leggyorsabbja!!!A MyISAM egy kompakt indexálást és táblakapcsolatokat támogató táblatípus, amely tranzakció kezeléssel nem rendelkezik. Ezzel szemben egy webes alkalmazásra és sebességre optimalizált tranzakció biztos táblatípus, az InnoDB. A BerkleyDB-hez hasonlatos, de annál lényegesen gyorsabb és stanilabb megvalósítás.
sipdav
Mindíg fontos, hogy milyen táblatípust használsz! A nem tranzakció biztos táblatípusok kb 10~15%-kal kevesebb memóriát és/vag tárhelyet igényelnek, de ha INSERT, UPDATE, vagy DELETE/DROP közben szakad meg a végrehajtás nagyon bonyolult, a hibás adatok visszaállítása. A tranzakció biztos táblatípusoknál csak akkor kerülnek az adatok rögzítésre, ha arra utasítod a kiszolgállót, illetve víssza is vonhatod a tranzakciót. Ha sokat írsz a táblába és fontos az adatok táblák közötti konzisztenciája feltétlenül a tranzakció biztos táblatípust érdemes használni. Ha inkább kiolvasod a tábla adatait felesleges a tranzakció biztosság, ez ugyanis növeli a gépigényt.
A többit a itt: http://dev.mysql.com/doc/refman/5.0/en/innodb.htmlVéleményem szerint az a profi megoldás, ha az adatkapcsolati táblák InnoDB típuak, a további táblák meg MyISAM típusúak (kecske is, káposzta is)
A MySQL egyébként sem bajnok. Eleinte gyors (MyISAM -al) aztán ahogy kezdesz pár 100e rekordot benyomni tragikusan lelsassul – ez nem elmélet, ez tapasztalat.
Az InnoDB mint db engine az egyedüli amivel a tranzakció kezelést is támogatja a rendzser, de mi van a relációkkal? A PostgreSQL ezt is azt is tudja helybõl, eleinte lassunak tünik, de ahogy „tömöd” rekordokkal ez stabil marad – aza nem lassul – másként van optimalizálva.
Végül is a kérdés kell e tranzakció kezelés, és mégis mekkora adatbázist kell lekezelni – mondjuk egy átlagos levelezõ program néhány ezer felhasználóval – erre pompás a MySQL. Viszont egy hypermarket raktárkezeléséhez ahol milliónyi rekord keletkezhet hetek alatt ez gyenge mint a harmat – neked kell döntened.PS: szempontként felmerülhet az egyéb szolgáltatások megoldása, cluster, mentések automatizálása, duplikáció vagy replikáció, és végül de nem utolsó sorban a programozói segédletek, tervezõ eszközök és a program megírását könnyítõ eszközök (RAD).
Pár 100 000 rekord ?
Barátom enyin még az Oracle -is csak cammog, ha a felylesztõ nincs észen (index, tranzakciók, relációk), mikor megtervezi az adatbátist.
Arról nem is beszélve, hogy az egekbe magasztalt PostgreSQL (tapasztalatból beszélek) kb 10-15% teljesítmény plussza van és ez sem a sebességben mutatkozik meg.
Egy jókis 4-6 táblából össze JOIN-olt, 80-90 oszlopból szûrt 15-20 oszlopnál, megspékelve egy kis LIKE-kal… Megnézem én mi befojásolja a sebességet. (biztos nem a „jobb” kód). Inkáb néhány varázssó: Opteron, RAID-SCSI 8GB-RAM…
Szóval ijenkor csak a nyers erõ ami segít!!!Ja és nem relációs adatbázis (ezt nem értem, hogy érted?), mert http://www.mysql.com/search/index.php?q=relational+database&base=http%3A%2F%2Fdev.mysql.com&lang=en&version=5.0&doc=1-4.1&m=a
Lehet hogy nem vagyok elég precíz;o( Számomra ott kezdõdik az adatbázis amikor relációs kapcsolatok vannak és kliens-szerver környezetben a referencia integritást a szervernek kell felügyelnie. Ha nincs „foreign constraints” akkor nincs integritás felügyelet …
Való igaz, hogy ahhoz hogy százezer (uram bocsá millió) rekordos adatbázis szervezése nem egyszerû. Ilyen esetekben a sûrûn alkalmazott összeállításoka külön kezeljük – menetközben létrehozzuk, redundáns táblákat alkalmazunk. Persze így is vannak lassú leválogatások de ezeket ritkán kell elvégezni, így nyugodtan rászánhatjuk az idõt. A lényeg a mindennapi munka zavartalanságán és gördülékenységén van – a többi már kutatás, leginkább hiba keresés, analízis.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz