Autor Zpráva
Jan Vyroubal
Profil *
Dobrý večer,

zajímalo by mne, logika délky datového typu. Při importu se mi automaticky nastaví například VARCHAR (900). Skriptem, který databázi prochází zjišťujeme pouze, zda je hodnota nulová (má / nemá informace) a kompletní obsah exportujeme až uživateli.

Dočetl jsem se, že při zmenšení hodnoty například na VARCHAR (1), se obsah "zkrátí". Z uvozovek jsem usoudil, že se neusekne, nezmizí, jen ho nebude databáze zobrazovat. Po obětovném nastavení VARCHAR (900) se zobrazí kompletní data.

Je to správná domněnka?

Děkuji
Joker
Profil
Jan Vyroubal:
Je to správná domněnka?
Možná jednodušší než psát celý ten dotaz by bylo to vyzkoušet.
Ale není správná (resp. možná záleží na typu databáze, ale dost bych se divil). Databáze nadbytečná data prostě zahodí.
iii
Profil *
Když budete mít krabičku dlouhou 10 cm a širokou 5cm, a dáte do ní metrovou tyč, neuseknce se, nezmizí, jen se nebude zobrazovat? A poté co krabičku zvětšíte na 1m zobrazí se celá?
Jan Vyroubal
Profil *
iii:
V tom jsem žil, ale překvapilo mne to zde http://programujte.com/clanek/2007052903-prehled-datovych-typu-v-mysql/.


Pro pole, kde nevím jaká bude délka mám použít jaký datový typ a jakou délku? Jak to funguje kdybych zde napsal například 10 000 znaků?
DJ Miky
Profil
V odkazovaném článku je toto:
Pokud je řetězec ukládaný do databáze delší než M, tak se zkrátí na délku M a zbytek se „ztratí“.

Zkrátí = usekne. Nadbytečná data databáze ořízne a zahodí. Při VARCHAR(1) se tedy uloží jen první znak a zbytek už nikdy neuvidíš.


Pro texty s proměnnou délkou existuje datový typ TEXT, případně TINYTEXT, MEDIUMTEXT a LONGTEXT, které se navzájem liší maximální délkou textu (v tebou odkazovaném článku jsou limity uvedené).
Jan Vyroubal
Profil *
DJ Miky:
Mám například pole, které obsahuje následující: 58100| 63000| 70200| 74000| 85590
To jsou sektory v jakých daný subjekt podniká.

V interním CRM z nich filtrujeme. Programátor mi vysvětloval, že je tento symbol odděluje |, což je logické, ale také zmiňoval, že skript, který je třídí, nemůže být v datovém typu TEXT, protože by oddělení nerozpoznal. Tahá mne tedy za nos?
abc
Profil
1) to je chybný návrh databáze, viz FAQ
2) monetálně jej to tedy uložené v jakém datovém typu?
3) záleží na tom, co ten skript vlastně dělá
DJ Miky
Profil
V prvé řadě se jedná o špatný návrh databáze, viz Některé časteji řešené dotazy pro MySQL - FAQ » Více hodnot ve sloupci. Tedy stačí udělat vazební tabulku M:N subjekt_sektor se sloupci id_subjektu a id_sektoru (předpokládám, že obě ID jsou číselná → datový typ INT), například to bude vypadat takto:

id_subjekt | id_sektor
    1      |   58100
    1      |   63000
    1      |   70200
... atd.

Po vytvoření indexů nad těmito sloupci budou dotazy na filtrování jednodušší a rychlejší.
Jan Vyroubal
Profil *
abc, DJ Miky:
Děkuji za informaci.

A pokud už tak máme řádově tisíce dat, jak je rozdělat do samostatných tabulek?
Lze to nějakým sql dotazem nebo neprogramovaným skriptem?


Pro nouzové řešení - dokáže datový typ TEXT rozpoznat více hodnot oddělených - |?
Slouží to k tomu, že si vyberu jaký typ firmy v CRM mne zajímá (vesměs něco jako štítek převedený do kódu).
abc
Profil
Lze to nějakým sql dotazem nebo neprogramovaným skriptem?
Nejjednodušší bude imho:
1) vytvořit novou tabulku se 2 sloupci
2) projít celou stávající tabulku
3) hodnoty rozdělit
4) naplnit novou tabulku


Pro nouzové řešení - dokáže datový typ TEXT rozpoznat více hodnot oddělených - |?
Nerozumím, co si mám představit pod "rozpoznat"

Slouží to k tomu, že si vyberu jaký typ firmy v CRM mne zajímá (vesměs něco jako štítek převedený do kódu).
To mě napadlo, ale záleží na tom, jakým způsobem to ten skript dělá, tzn. jak je napsaný
Sir Tom
Profil
Jan Vyroubal:
Pro nouzové řešení - dokáže datový typ TEXT rozpoznat více hodnot oddělených - |?
Ne - ale můžeš vyhledávat, zda-li se v řádku nachází určitá část řetězce.

abc:
A pokud už tak máme řádově tisíce dat, jak je rozdělat do samostatných tabulek?
Tak jak píše abc. Lepší to udělat teď, než až bude v tabulce milion záznamů.
jenikkozak
Profil
Ne - ale můžeš vyhledávat, zda-li se v řádku nachází určitá část řetězce.
Je však třeba zmínit, že toto hledání bude mnohonásobně pomalejší, než kdyby byly jednotlivé hodnoty uloženy samostatně jako čísla. Počítat s těmi čísly nebo jednotlivé hodnoty upravovat bude dost obtížné.
Jan Vyroubal
Profil *
jenikkozak:
Sir Tom, abc:
V databázi mám tolik hodnot, že manuálně bych je upravoval 2 měsíce.
Mám cca dalších 7 třídících parametrů, které už jsou samostatné (jedna hodnota), dalších 30 jsou dodatečná pole, která neslouží k filtraci, ale zobrazují se u vyfiltrovaných položek. Například jméno kontaktní osoby,..

Abych zrychlil běh, mám každý třídící parametr nechat naimportovat do samostatné tabulky s ID a zbylá pole (30) nechat v tabulce jedné?
Každý subjekt má vlastní univerzální číslo - IČO. I přes to mám vytvořit sloupec ID a identifikovat podle něj?

Děkuji a děkuji.
abc
Profil
V databázi mám tolik hodnot, že manuálně bych je upravoval 2 měsíce.
Když už máte toho programátora, tak by Vám na to mohl naprogramovat nějaký skript, který by to mohl dělat 30 minut (i s psaním skriptu)

Abych zrychlil běh, mám každý třídící parametr nechat naimportovat do samostatné tabulky s ID a zbylá pole (30) nechat v tabulce jedné?
Znovu si přečtěte odkazovaný článek ve FAQ z příspěvků [#7] a [#8]

Každý subjekt má vlastní univerzální číslo - IČO. I přes to mám vytvořit sloupec ID a identifikovat podle něj?
Záleží na tom, jaký má tabulka "subjekty" primární klíč - pokud IČO, tak IČO; pokud ID, tak ID
Jan Vyroubal
Profil *
abc:
Děkuji za rady. Programátorovi zadám.

Jestli jsem pochopil správně, jestliže je ICO unikátní hodnotou, může nahradit ID a tak se stává ID bezpředmětné.
Sir Tom
Profil
Jan Vyroubal:
Jestli jsem pochopil správně, jestliže je ICO unikátní hodnotou, může nahradit ID a tak se stává ID bezpředmětné.
V podstatě ano, ale záleží jestli nějaká aplikace s tím ID nepracuje. Pokud ano, tak vyhozením ID sloupce můžeš způsobit katastrofu. Já bych jen tak ze zvyku (pro jistotu) nechal ID unikátní a ICO ať si je, jaké chce.
Jan Vyroubal
Profil *
Sir Tom:
Dobře, děkuji. Primární klíč bude tedy ID a tabulku nechám rozdělit na více částí. Někde v diskuzi jsem se dočetl, že InnoDB neumí vyhledávat ve více tabulkách podle ID, je to tak, nebo je to fáma?

Děkuji.
Sir Tom
Profil
Jan Vyroubal:
InnoDB neumí vyhledávat ve více tabulkách podle ID
Jak to myslíš?
Jan Vyroubal
Profil *
Sir Tom:
Všeobecně se píše, že rozdíl mezi InnoDB a MyISAM je ve způsobu práce s dat. Jedna lepší v zápisech, druhá ve čtení. U nás je to rovnoměrné - hodně se doplňuje a hodně se tahá. Navíc jsem se dočetl, že MyISAM je cca o 30% rychlejší.

A také jsem se dočetl, že vlastnosti, které InnoDB nemá - klíče pro fulltextové vyhledávání. My v databázi vyhledáváme.

Ptám se, protože při importu dat se mi automaticky ukládají v InnoDB.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: