Dotaz: mysql nebere jako jmeno tabulky ip adresu

[petka]

Chci vytvorit tabulku pro ip napriklad 192.168.0.3 a server mi vyhodi chybu .

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '192.168.0.3 (datum date,data_out int,data_in int)' at line 1

Pokud mu dam jmeno obycejne slovo tak se tabulka vytvori. V phpmyadmin tabuku s jmene ip adresy vytvorim , ale ja to potrebuju vkladat shellem.

---

---

Odpovědi

[Jendа]

Dej sem celý SQL dotaz…

[petka]

shell prikaz

mysql -N -D $DB_DB  -u $DB_USER -h$DB_HOST -p$DB_PASS -e "CREATE TABLE '192.168.0.3' (datum int,data_out int,data_in int)"

[chrono]

Použil si znaky `` aby MySQL vedelo, že to nie je len náhodné číslo?

[petka]

pokud pouziju `` tak

./ipaccount_sql.sh: line 106: 192.168.0.3: command not found
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(datum int,data_out int,data_in int)' at line 1

a kdyz pouziju '' tak ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''192.168.0.3' (datum int,data_out int,data_in int)' at line 1

[petka]

"CREATE TABLE \`192.168.0.3\` (datum int,data_out int,data_in int)"

[petka]

Dekuji moc , taky me napadlo osetrit to jako v php lomitkem , ale z nejakeho duvodu jsem to nezkusil

[Josef Kufner]

A k čemu takovou ošklivou věc vůbec potřebuješ?

[poky74]

Samozřejmě že nepotřebuje, jen mu asi nedošlo že je to prasárna a že takhle se to prostě nedělá.

[Michal Kubeček]

Mám temné podezření na nesmyslně navržený datový model (co adresa, to tabulka?).

[pht]

Taky bych to tak viděl.

[Josef Kufner]

Však právě proto se ptám

[petka]

Ma nekdo lepsi reseni ?

[Heron]

Pokud napíšeš co to má vlastně dělat, tak ti můžeme pomoci s vhodnějším návrhem schématu. Z toho dotazu a diskuse toho mnoho poznat není, tedy kromě velmi špatného návrhu typu jedna entita - jedna tabulka, 2^32 tabulek žádná DB nebude dobře snášet, naproti tomu stejný počet záznamů v tabulce zvládne levou zadní.

[petka]

Zapis se provadi pro jednu unikatni IP . Pro kazdou IP je tabulka s informacemi o hostu mac nastavene rychlosti atd ... Nevim o nicem lepsim jak popsat hosta nez podle IP.

[Heron]

Nevim o nicem lepsim jak popsat hosta nez podle IP.

Toto je v pořádku, pokud jsou IP unikátní a jednoznačně identifikují hosta.

Pak IP by mohla sloužit například v tabulce "nastaveni" jako primární klíč. Další prvky by pak byly: mac, rychlost atd se vhodnými datovými typu. Případně odkázané přes cizí klíče do dalších tabulek (například to tabulky s osobami) dle normálních forem. Tedy nikoliv co IP to tabulka, ale jedna tabulka a co řádek to IP.

[petka]

Ale ja potrebuji 365 zaznamu na jednu ip .

[Michal Kubeček]

Pořád nechápu, v čem je problém. Prostě budete mít jeden sloupec pro IP adresu a jeden pro datum.

[petka]

Chci to mit jako nahradu za rrd databazi . Rrd db je sice rychlejsi , ale pro vypocet a nasledne matematicke operace , ktere zaberou vic casu nez cteni pripravench dat z mysql . Rrd db se taky uklada zvlast pro kazdou IP . Nedokazu si predstavit co ip tak sloupec .

[Heron]

Nedokazu si predstavit co ip tak sloupec

Proč zase sloupec? ŘÁDEK!

Tabulka se sloupci např. ip UNSIGNED INT, cas DATETIME, incoming BIGTINT, outcoming BIGINT atd. Primární klič na (ip, cas) a podle verze MySQL ještě třeba další samostatný index nad sloupcem cas. Pak si můžeš psát dotazy typu WHERE `ip`=nejaka_ip AND `cas` BETWEEN datum1 AND datum2.

[Michal Kubeček]

Nedokazu si predstavit co ip tak sloupec.

Proboha, nic takového jsem přece nepsal, ba ani nenaznačil, to by byla v podstatě stejná šílenost jako "co adresa, to tabulka". Prostě si uděláte strukturu ve stylu např.

  create table HOSTS (
    IPADDR bigint primary key,
    NAME varchar(32),
    ...
  );

  create table TRAFFIC (
    IPADDR bigint not null references HOSTS(IPADDR),
    RDATE date not null,
    DATA_IN bigint,
    DATA_OUT bigint,
    primary key (IPADDR,RDATE)
  );
  create index IDX_TRAFFIC_DATEADDR on TRAFFIC(RDATE,IPADDR);

Pokud trváte na tom, že dat nesmí být moc, tak třeba jednou za měsíc záznamy starší než rok smažete, ale nehodláte-li těch počítačů evidovat statisíce, tak k takovému počínání nevidím důvod.

[Heron]

Pokud trváte na tom, že dat nesmí být moc, tak třeba jednou za měsíc záznamy starší než rok smažete

Případně je přesune to tabulky archiv (klidně i používající stejnojmenný engine) nebo ještě lépe: nastaví paritioning.

[petka]

Tady jde zřejmě o nepochopení jak se pracuje s databázemi a tabulkami.
Kdyby jste se nezdráhal říct, co opravdu potřebujete, třeba by Vám i někdo poradil více.
Zkusím jen nakopnout, zkuste si následující:

CREATE TABLE tabulka (`ip` varchar(15),`datum` date,`data_out` int, `data_in` int);
ALTER TABLE `tabulka` ADD PRIMARY KEY (`ip`, `datum`);

INSERT tabulka (ip,datum,data_out,data_in) VALUES ('192.168.1.1','2009-12-01',10,20),
 ('192.168.1.1','2009-12-02',11,21),
 ('192.168.1.1','2009-12-03',15,25),
 ('192.168.1.2','2009-12-01',1110,550),
 ('192.168.1.2','2009-12-03',100,200);

SELECT * FROM tabulka WHERE `ip`='192.168.1.1';
SELECT * FROM tabulka WHERE `datum`='2009-12-01';
SELECT * FROM tabulka WHERE `ip`='192.168.1.1' AND `datum`='2009-12-01';
SELECT SUM(`data_out`) AS `out`, SUM(`data_in`) AS `in` FROM tabulka;
SELECT SUM(`data_out`) AS `out`, SUM(`data_in`) AS `in` WHERE `ip`='192.168.1.1';
SELECT SUM(`data_out`) AS `out`, SUM(`data_in`) AS `in` FROM tabulka  WHERE `datum`='2009-12-01';
SELECT SUM(`data_out`) AS `out`, SUM(`data_in`) AS `in` FROM tabulka  WHERE `ip`='192.168.1.1' AND  `datum`='2009-12-01';

[Heron]

`ip` varchar(15)

Špatně. IP(v4) je 32b, tedy typ UNSIGNED INT -- operace s tím budou daleko rychlejší než s varcharem (a to nemluvě o potenciální možnosti použít bitové operace) a zabere to méně místa.

[Michal Kubeček]

A na rozdíl od řetězcové reprezentace se to bude i správně řadit.

[Šangala]

Netroufl jsem si nic takového navrhovat :), ale aspoň typ date jsem opravil.
Ukázka nebyla jako návrh konečného řešení, ale na pochopení jak se pracuje se záznamy.
PS: špatně – silné slovo, pokud neznáte konečný účel…

[petka]

Opravdu je to zakladni neznalost z me strany , jeste by me zajimala konstrukce podminky kdy data se budou jen aktualizovat jestlize datum uz existuje v opacnem pripade vytvori novy zaznam .

[petka]

INSERT ... ON DUPLICATE KEY UPDATE

[petka]

Funguje diky moc .

[Michal Kubeček]

A i kdyby těch adres bylo výrazně méně, půjde takový absurdní datový model rozumně používat jen pro dotazy týkající se jedné adresy. Jakýkoli report typu "seznam počítačů s údaji o nich" bude horor a v případě, že s tím nedej bože bude muse pracovat ještě někdo další, může dojít i k ohrožení zdraví nebo života.