Warden

Na serveru warden-c jsem zacal pracovat na propojeni tabulky events s clients. Dival jsem se po moznych resenich a jako nejlepsi mi pripada pouzit FOREIGN KEY client_id v tabulce events. Tabulky jsem tedy timto zpusobem propojil a prikladam postup:

Zmena DB Enginu na InnoDB
-------------------------
http://www.neiland.net/blog/article/creating-a-foreign-key-in-mysql/
http://kb.siteground.com/how_to_change_the_database_engine_of_a_mysql_database_table/

    mysql> ALTER TABLE events ENGINE = InnoDB;
    mysql> ALTER TABLE clients ENGINE = InnoDB;

Pridani ciziho klice:
---------------------
http://forum.c4.cz/phpmyadmin-vlozeni-ciziho-klice-t970.html

-> pridani sloupce client_id do events:

    ALTER TABLE events ADD client_id INT(11);

-> pridani ciziho klice

    ALTER TABLE events ADD FOREIGN KEY (client_id) REFERENCES clients (client_id);

Zruseni duplikatnich sloupcu
----------------------------

    mysql> ALTER TABLE events DROP hostname;
    mysql> ALTER TABLE events DROP service;

Pridani udalosti
----------------
INSERT INTO events VALUE (NULL,'2013-04-17 00:00:00','2013-04-17 01:00:00','dos','IP','1.1.1.1','TCP','666','1','note','1','1','t','2');

K cizimu klic lze take definovat klauzue ON UPDATE (akce) a ON DELETE (akce) u kterych si ale nejsem jist, zdali nam k necemu budou. Pavle, souhlasis s tim takhle?

Změna formátu tabulek je velká změna, skutečně je nutná?

• Jaké mohou být výkonové důsledky?
• FOREIGN KEY constrainty jsou záležitost pro poněkud více enterprise aplikace, kdy je potřeba, aby databáze sama kukala při porušení integrity. To potřebujeme?

Jake jsou pozadavky dalsiho vyvoje? A co si vlastne od FOREIGN KEY slibujes? Podle meho neni zmena db formatu tak zcela zasadni, ale pokud ti jde pouze o zaruceni toho, ze se nesmaze event client_id, kdyz k nemu budou existovat events, tak bych si to poresil aplikacne. Nebo mas jiny duvod?

Tomáš Plesník wrote:

V DB serveru je potreba pro dalsi vyvoj serveru vytvorit propojeni tabulek clients a events pomoci client_id.

OK, byl to jen navrh, hned mne nekamenujte . Muzeme to tedy udelat tak, jak jsem si puvodne myslel a to, ze pouze do tabulky events pridame client_id, ktere nebude FOREIGN KEY, ale normalni var(11) sloupec a bude se do nej zapisovat ID klienta, ktery udalost ulozil. Od FK jsem si sliboval pouze zajisteni integrity dat, ale uznavam ze pro nase ucely je to zbytecne. Tuto zbytecnost navic podtrhuje i fakt, ze validita polozek v tabulce events neni pouze T/F, ale v 2.2 budeme pouzivat notaci T - true, O - obsolete, F - fail. Dale jsem si jeste od FK sliboval, ze v budoucnu budeme moct vyuzit klauzuli ON UPDATE (akce).

Berte to prosim jako prvotni pokus a rozvireni debaty s vice lidmi, nez abych to nejak vymyslel sam a sel spatnou cestou. Co tedy rikate na navrh cislo 2 a to pridat do events sloupec client_id var(11) a v kodu uz si osetrim to, aby se s timto sloupcem spravne pracovalo a nevznikl nam rozkol v databazi. Diky za napady, je lepsi se o tom poradit, nez to vymyslet sam a spatne. Tom

Nekamenujeme, jen se ozýváme, když nám něco přijde jako overkill, to nutně neznamená, že bys pro svá rozhodnutí neměl dobré důvody.

V tomhle případě jsem pro jednodušší variantu - pouze client_id:int(11). Integritu si zkontrolujeme Kubovým skriptem a hlavně: nebrání nám to referenční integritu zavést, ukáže-li se, že by se hodila. ON UPDATE a podobným záležitostem, které už můžou zavádět závislosti na SQL dialektu, bych se prozatím vyhýbal, nezavřeme si cestu nejen ke změně formátu db, ale třeba ke změně celé db.

Jasny, je treba se jen domluvit. Jak pise PH, snazil bych se pro vsechna id pouzivat INT, protoze se dobre indexuje a slozitejsi vyhledavani je pak pekne rychle.

Dobra tedy. Do tabulky events pridam sloupec client_id:int(11) a zaroven z ni smazu sloupce hostname a service, jelikoz tyto udaje budou ulozeny v tabulce clients a jednoznacne identifikovany pomoci client_id v events.

PS: s tim kamenovanim to byl jen vtipek

Diky za rady a nazory,

Tom