abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 3
dnes 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 4
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 9
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 24
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 4
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 771 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Sql primary key

10.9.2014 17:20 Jiri
Sql primary key
Přečteno: 2520×
Rekneme, ze chci vytvorit tabulku CLOVEK s atributy jmeno (TEXT) a pohlavi a pak jeste druhou tabulku PES ktery bude mit forein key na data v tab. CLOVEK. Moje otazka je, co mam nastavit jako primary key v tabulce CLOVEK? Mam pridat do CLOVEK jeste sloupec id (INT) nebo staci jako prim. key nastavit sloupec jmeno? Udelat jdou urcite oba zpusoby.

Predpokladam, ze kdyz pouziji jmeno jako prim. key, tak forein key v tabulce PES bude take typu TEXT a tudiz zbytecna narocnost na pamet a pomalejsi vyhledavani z duvodu slozitejsiho porovnavani. Je to tak, nebo bude forein key nejaky hash?

Kdyz pridam id, tak sice pridam dalsi sloupec, ktery de facto nepotrebuji, ale usetri mi to pamet a zrychli vyhledavani. Je to tak? Diky.

Odpovědi

10.9.2014 17:44 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
Rozbalit Rozbalit vše Re: Sql primary key
jako prim. key nastavit sloupec jmeno
Jmeno jako JEDNOZNACNY identifikator? IMHO docela hloupe...
Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
10.9.2014 17:55 Jiri
Rozbalit Rozbalit vše Re: Sql primary key
Jedna se o ukazkovy priklad. Pod pojmem jmeno si predstavte vzdy unikatni text...
Tarmaq avatar 10.9.2014 18:25 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
IMHO neni problem mit jako primarni klic jmeno (pokud je unikatni). Rozhodne bych ale doporucil misto typu TEXT pouzit napr. VARCHAR(32)
Don't panic!
10.9.2014 22:36 Jiri
Rozbalit Rozbalit vše Re: Sql primary key
IMHO neni problem mit jako primarni klic jmeno (pokud je unikatni).
V otazce jsem psal, ze vim, ze to lze, ale moje otazka je: jaky zpusob a v jakem pripade dany zpusob pouzit? Predpokladam, ze jsou pripady pro ktere se hodi vzdy jiny...

Rozhodne bych ale doporucil misto typu TEXT pouzit napr. VARCHAR(32)
Proc? Ma to nejaky vliv na to na co jsem se ptal, nebo se pouze jedna o setreni pameti?

P.S. Podotykam, ze jde jen o priklad, takze prosim nepiste odpovedi, proc resim 4 byty na id, kdyz jich mnohem vic plytvam na zvolenem datovem typu pro text (tedy pokud to nema vliv na forein key).
11.9.2014 21:53 j
Rozbalit Rozbalit vše Re: Sql primary key
Technicky ... mas pravdu, realne ... je to nejvetsi hovadina jakou muzes udelat.

id by NIKDY nemela byt data, ktera lze jakkoli editovat. id je idealne int, protoze jestli neco funguje opravdu rychle, tak je to nalezeni spravnyho cisla. Jakejkoli string bude nekolikanasobne pomalejsi. U jednoduchy vazby se to nijak zvlast neprojevi, ale jakmile zacnes pripojovat dalsi a dalsi tabulky, pres stringy ... tak dotaz misto vterin muze trvat desitky minut (a to pocitam s tim, ze pro tebe index neni sprosty slovo).
xkucf03 avatar 11.9.2014 22:44 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Platí to i pro texty s pevnou délkou? V obou případech je to jen porovnání posloupností bajtů (číslo je taky n-bajtů). Lišit by se to mohlo v případě Unicodu, kde různé posloupnosti bajtů můžou znamenat tentýž text. Ale pokud to budou třeba nějaké kódy v ASCII s pevnou délkou?

Jinak co se týče těch změn, tak souhlasím – PK by se neměl měnit. On totiž PK začne časem prosakovat i do jiných systémů nebo třeba do logů a tam už to nezměníš vůbec (v rámci jedné databáze to přeci jen jde pomocí kaskády).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
okbob avatar 12.9.2014 09:39 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Sql primary key
Záleží na databázi - implementačně znám jenom Postgres, a tam není rozdíl mezi uložením charu a varcharu .. a i s krátkým varcharem je výrazně větší režie než z číslem. Dalo by se to pořešit vlastním datovým typem, ale to už je pro běžné uživatele mimo jejich možnosti (i když to může být jen pár desítek řádek v C), a také by to mělo smysl jedině u extrémně zatížených a větších databází. Dovedu si ale představit, že na 64bit mašinách už do 8byte může být uložený relativně slušný obsah s větší informací než má obyčejné číslo. Před 10 roky jsem experimentoval, a do 4byte zakódujete rodné číslo, v 8 třeba hash jména.
xkucf03 avatar 12.9.2014 10:21 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Postgres, a tam není rozdíl mezi uložením charu a varcharu .. a i s krátkým varcharem je výrazně větší režie než z číslem.

A čím to je dané? Že je potřeba převést ty bajty na text pomocí určitého kódování a pak teprve porovnat?

Ještě mě napadlo použít pole s pevnou délkou, pak by to mělo být teoreticky 8 bajtů (pole) jako 8 bajtů (číslo). Ale v dokumentaci jsem našel:

However, the current implementation ignores any supplied array size limits, i.e., the behavior is the same as for arrays of unspecified length.

Takže asi použít ten BIGINT a do něj si kódovat, co potřebuji, pomocí nějaké funkce nebo v aplikaci. Ale asi bych se na to vykašlal a použil buď klasické sekvenční ID nebo znakový kód.

BTW: kde je ta hranice, kdy má smysl tohle řešit? Kdy se dají používat několikaznakové kódy a kdy už je lepší použít číselné ID (za cenu toho, že bez JOINu z toho na první pohled člověk nic nezjistí)?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 12.9.2014 11:24 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Sql primary key
Hranice? Reakce na akci uživatele do cca 200ms, pokud do té doby ukážeš progressbar, tak jednotky sekund.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 12.9.2014 12:29 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Šlo mi spíš o počty řádků (a/nebo objem dotazů a HW). Jsou spousty aplikací, kde se do těch 200 ms dostaneš klidně i bez indexů :-) (a přesto ty aplikace dělají něco užitečného)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 13.9.2014 17:54 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Sql primary key
Ono hodně záleží na povaze dat a způsobu práce s nimi. Nejlepší je nedělat příliš velké zrůdnosti a když to bude příliš pomalé, tak to zoptimalizovat či přepsat.
Hello world ! Segmentation fault (core dumped)
okbob avatar 13.9.2014 07:52 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Sql primary key
Je to dané designem datových typů v Postgresu. V Postgresu se dělí typy na fixní a tzv varlena. To, co má pevnou velikost a zabírá stejně místa jako pointer na dané platformě je fixní, vše ostatní je varlena. Varlena je text, numeric, varchar - ale také na např. Int64 na 32bit platformě. A jelikož může mít Char(X) různou velikost, tak je implementován nad varlena typem.

Kdy to bude mít smysl -- to se nedá od boku říct -- záleží na rychlosti CPU, sběrnice, IO. Navíc, každý typ má jinou estimační funkci, což znamená jiné odhady, jiné prováděcí plány -- což by asi mělo mít podstatně větší efekt než to, jak je ta či ona hodnota uložená. Dlouho jsem neviděl nějakou studii, která by to řešila. Nikoho to zvlášť nezajímá, v OLTP by se to asi nepoznalo, a v OLAPu se řeší sloupcové databáze, a jde se na to úplně jinak.
rADOn avatar 12.9.2014 14:26 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Sql primary key
Tahle numericka manie je zbytecna. Pokud je nad sloupcem index tak je jedno jestli je to cislo nebo text. A kdyz je ten text unikatni a nemenny tak je jako PK naprosto dostacujici. Pokud by nejaka databaze projevovala tak velke vykonove rozdily jakymi strasis, tak je to spis chyba v implementaci.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
12.9.2014 17:31 j
Rozbalit Rozbalit vše Re: Sql primary key
Az se dostanes nekdy k realny databazi, tak si povime ... mam tu takovou pididatabazicku cca 150GB ... nektery dotazy pred tim, nez sem do toho zasah vlastnima modifikacema (samosebou nepodporovanyma dodavatelem) trvaly desitky minut ... joooo tomu se dneska rika optimalizace, kdyz neco zrychlis 1000x ... belvaly casy, kdy ze domu rikalo prasecka implementace.
rADOn avatar 13.9.2014 16:19 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Sql primary key
No tak povidej, jsem zvedavej co zajimavyho se jeste dozvime.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
19.9.2014 18:18 Ivan Nový
Rozbalit Rozbalit vše Re: Sql primary key
Všechny tabulky by měly mít pevnou strukturu absolutně bez výjimek:

1. systémovou část: - id_entita (číslo automaticky generované v aplikaci neviditelné, nezaručující estetickou posloupnost) - id_entita_1 (stejný typ jako PK, automaticky generovaný) ... - id_entita_n

2. identifikace entity ve formátu vhodném pro lidi - reference - znaky a čísla, zajišťuje estetickou posloupnost - name

3 datová část - Hodnota 1 ... - Hodnota n

4. transakční část - date_create - date_upd - active - deleted

A každá odchylka od zvolené struktury při návrhu databáze znamená v budoucnosti spousty chyb a ztraceného času. I ta nejblbější a nejdočasnější tabulka by měla mít stejnou strukturu.
rADOn avatar 22.9.2014 10:40 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Sql primary key
Tak to jsem ty spousty chyb nějak nezaznamenal
"2^24 comments ought to be enough for anyone" -- CmdrTaco
22.9.2014 14:42 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Souhlas.
27.9.2014 18:43 singerko
Rozbalit Rozbalit vše Re: Sql primary key
Nie je to tak uplne jedno, pretoze index ta len rychlejsie "presunie" na subor dat ktore mu zodpovedaju a v ramci tejto mnoziny dat uz musis porovnavat reqvencne.
xkucf03 avatar 10.9.2014 19:22 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Co bude primární klíč, by mělo vycházet z logiky věci. Není potřeba cpát všude umělé klíče (sekvenčně generované id). Na druhou stranu se to chce zamyslet, co bude s databází v budoucnu, jaké změny tě asi čekají… Často u toho číselného id nakonec stejně skončíš. Např. proto, že uživatelské jméno se taky může změnit (stejně jako příjmení). Primární klíč by měl být hodnota, která se nikdy nezmění.

Vedle primárního klíče (třeba to tvoje jméno) můžeš mít i další sloupec (třeba to číselné id), který bude UNIQUE. Tzn. taky jedinečné hodnoty.

Cizí klíč se může odkazovat na cokoli, ne jen na primární klíč… ale je dobré, aby ten odkazovaný sloupec měl alespoň nějaký index.

Pokud je to školní úloha, tak je celkem jedno, jak to uděláš – nemáš dostatek informací o systému, zadání je neúplné… – ale je důležité, aby sis dokázal obhájit, proč jsi to udělal zrovna takhle, co tě k tomu vedlo a jaké jsou výhody a nevýhody dalších řešení.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
10.9.2014 22:20 Jiri
Rozbalit Rozbalit vše Re: Sql primary key
Dobre jinak. Chci treba udelat slovnik. Mam tabulku SLOVICKA se sloupcem slovicko (VARCHAR). Dale mam SLOVNIK a ten ma dva sloupce slovicko, preklad (oba forein keys) ktere odkazuji do tabulky SLOVICKA. Otazka: ma se pridavat do tabulky SLOVICKA jeste sloupec id (INT) pro rychlejsi praci a a "mensi" pametove naroky? Ano/ne a proc byste tak udelal pro tento konkretni priklad.

Porad si to predstavuji, ze kdyz zvolim jako prim. key slovicko, ktere je text, tak zakonite budou stejna data ulozena i ve forein key (zbytecne pametove naroky). A z toho mi vypliva, ze to budu JOINvat zhruba pres WHERE SLOVICKA.slovicko = SLOVNIK.slovicko a toto porovnavani nutne musi byt daleko narocnejsi nez kdyz budu porovnavat indexy (cela cisla). Nebo se snad indexaci sloupce SLOVICKA.slovicko neco meni?
11.9.2014 21:55 j
Rozbalit Rozbalit vše Re: Sql primary key
Viz vejs, vazba pres text je vzdy pomalejsi. Ne nutne vzdy to ma smysl resit, ale ...
11.9.2014 22:48 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Vazba přes text není vždy pomalejší. Číselný primární klíč, který je do tabulky vložen nadbytečně, může dokonce i zpomalit dotazy.

Rozhodně není možné paušalizovat, že by primární klíč měl být vždy syntetický a číselný, i když ve většině případů je to výhodné.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
12.9.2014 17:34 j
Rozbalit Rozbalit vše Re: Sql primary key
Vazba pres text je pomalejsi, musis porovnat dva stringy, kde musis brat ohled na spoustu ruznych dalsich parametru (kodovani ...) vs jedno cislo.
12.9.2014 20:58 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

To je takové plácání, ano numerický typ je ve valné většině případů lepší, ale jen proto, že má obvykle vyšší efektivitu uložení a to důležité je, aby klíč (nejen primární) byl co nejmenší, to je to co ovlivní (zvláště při velkých datech) rychlost a nároky.

Za prvé ten klíč má index, takže ke konečnému porovnávání string-ů dochází velmi málo a za druhé, porovnání string-ů může být za určitých okolností dokonce méně náročné než porovnání čísel, zvláště když známe jejich uloženou délku, takže prohlásit, že vazba je přes text vždy pomalejší je takové „plác“…

Určitě záleží i na DBE, a třeba i na tom kolik, znaků textového pole je indexováno (může-li to daný DBE limitovat).

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
3.1.2015 21:27 Jiri Horky
Rozbalit Rozbalit vše Re: Sql primary key
Rozumim tomu, ze nemate radi pausalizovani, a neberte to jako trolovani, ale v jakem pripade muze byt porovnavani stringu rychlejsi nez porovnavani cisel? Neumim si predstavit, jak muze byt neco rychlejsiho nez jedna instrukce procesoru.

Naopak jsem na realne PostgreSQL databazi s indexem nad varcharem videl, ze je upecena na CPU prave nad porovnavanim stringu (C funkce strcoll - tj. navic bere do uvahy locale).
4.1.2015 10:10 Ivan
Rozbalit Rozbalit vše Re: Sql primary key
Tak treba v Oracle je to tak, ze kazdy soupec je ulozen jako:
1 byte: datovy typ
1 byte: delka (ala Pascalovska konvence pro stringy)
n bytes: jednotlive znaky stringu.
pokud jde o cislo tak to je ulozeno podobne. Prvni bajt obsahuje sign a exponent pak nasleduje BCD kod. Kazdy nible obsahuje jednu cislici (mantisa). Celkem to muze byt az 38 platnych cislic. Takze porovnavani cisel je v podstate stejne jako porovnavani cislel. U typu NUMBER sice platne cislice zabiraji polovinu bajtu, ale zase mate navic povinny bajt pro exponent. Jednou instrukci procesoru muzete porovnat cisla jen pokud odpovidaji interni reprezentaci procesoru.
12.9.2014 21:21 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Může to být klidně i obráceně, že vazba přes text bude rychlejší. Záleží na konkrétním případu. Nelze paušálně tvrdit, že vazba přes číslo je rychlejší.

Kromě toho při správném návrhu databáze nehraje rychlost porovnávání příliš významnou roli.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
10.9.2014 23:41 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Důvod, proč je zvykem jako PK používat číselný sloupec (v případě vazební tabulky oba sloupce) je čistě paměťová náročnost.

Možná je zajímavé si připomenout, že v kontextu relační algebry, je požadavek na PK jedinečnost na úrovni tabulky. Nic víc, nic méně. Jedná se jakousi analogii k Céčkovskému odkazu na instanci. Tam také nepracujeme s konkrétní hodnotou dotyčného odkazu, ale spíše nás zajímá, zda se jedná o stejnou instanci, nebo o dvě instance, které jsou shodou okolností zcela identické.

11.9.2014 00:57 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Sql primary key
U identifikátoru je výhodné, pokud nemá žádný reálný smysl (v reálném světě nic nepředstavuje). Z toho totiž vyplývá, že nikdy nevznikne potřeba jej měnit. Neměnnost a jedinečnost jsou u identifikátru nutné podmínky.

Zda je identifikátorem číslo nebo text je vedlejší. Je vhodné zvolit datový typ, který zabere málo místa, dobře a rychle se porovnává a má dostatečný rozsah. Celé číslo tomuto dobře vyhovuje a proto se často používá.
-- OldFrog
11.9.2014 06:52 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Osobní číslo zaměstnance může mít reálný smysl a přitom je tím pravým kandidátem na primární klíč. Za použití rodného čísla jako PK bych však fackoval.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
11.9.2014 22:06 j
Rozbalit Rozbalit vše Re: Sql primary key
Ne, neni, osobni cislo se muze zmenit ... vzpomene si personalistka, ze generalni reditel prece nemuze mit 89, kdyz ma uklizecka 1 ... a budes resit precislovani. Viz vejs, id by melo byt pole, ktere nikdy nikde nefiguruje, neni nikde v aplikaci videt, uzivatel o nem vubec netusi a tak nema blby napady, a nemeni ho.

Muzu klidne uvest desitky pripadu, kdy tomu tak neni, a je to vzdycky jeden velky pruser... Osobne trebas adminuju skladovej system napojenej do erpcka, kterej jako ID pouziva neco, cemu rikaj v erp cislo karty/produktu ... a samozrejme to chteji menit ... protoze si do toho (a je jedno proc) pisou veci jako ze to je ve vyprodeji/nedostupny/...

Ted by te mozna napadlo, ze u produktu je to spravny cislo EAN ... heh, zapomen, mas 5 dodavatelu, ti dodavaji jakejsi produkt a ty potrebujes v systemu sice odlisovat produkty tech 5ti dodavatelu, ale dal to uz je produkt jeden, s jednim EANem ...
11.9.2014 22:33 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
EAN má pro mne stejnou vypovídací hodnotu jako zmíněné rodné číslo. Proto bych ho jako primární klíč nepoužil. Naopak výrobce produktu ho jako primární klíč použít může.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
12.9.2014 17:37 j
Rozbalit Rozbalit vše Re: Sql primary key
Nemuze ... cukrovar dala cukr, ten ma porad stejny ean, ale oni vyrabej kilovy balicek, pak 10kg krabici ... a tunovou paletu. Pochopitelne existuje asi 10 ruznyzh zpusobu, jak tyhle veci oznacovat (v EAN kodu), ale odberatel si (taky naprosto bezne) zvoli vzdy ten nejblbejsi => on objednava cukr, nechce objednavat paletu nebo krabici ... ale cukrovar potrebuje vedet, jestli mu paletu nebo krabici ma dodat.
xkucf03 avatar 12.9.2014 17:59 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
cukrovar dala cukr, ten ma porad stejny ean

vs.

ale oni vyrabej kilovy balicek, pak 10kg krabici ... a tunovou paletu. Pochopitelne existuje asi 10 ruznyzh zpusobu, jak tyhle veci oznacovat (v EAN kodu)

Tak je to jeden EAN nebo deset různých?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Pavel Stárek avatar 22.9.2014 15:06 Pavel Stárek | skóre: 43 | blog: Tady bloguju já :-) | Kolín
Rozbalit Rozbalit vše Re: Sql primary key
Problém je, že jedno balení cukru má vždy stejný EAN. Čili třeba deset kilových pytlíků cukru = deset stejných EANů. Ovšem těch deset můžu zabalit strečkou a tento balík deseti cukrů označit jiným EANem, a pak můžu vzít tyto balíky a dát jich deset na paletu, a celé to zase můžu označit EANem. Ovšem krom EANů na jednotlivých pytlících by měly být další kódy jiné.
Kdo chce, hledá způsob; kdo nechce, hledá důvod.
xkucf03 avatar 22.9.2014 15:31 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Ovšem pak není problém až tak v těch EANech a jejich použitelnosti jako ID. Jde spíš o to, že výrobek může být složen z jiných výrobků a to se může ještě měnit, může se skládat nebo rozkládat, třeba koupíš paletu a prodáš pytlíky nebo naopak. A tohle skládání je potřeba podchytit v databázi/aplikaci.

Jestli použít EAN jako PK je jiná otázka. To si netroufám takhle bez dalších informací říct. Ptal bych se na otázky jako: budeme mít někdy výrobek bez EANu? Budeme mít výrobek, kterému se EAN změní1? Budeme mít dva rozdílné výrobky se stejným EANem.

…nicméně tahle diskuse je taková dost hypotetická – kvůli tomu se dělá analýza a nestřílí se to od boku jako komentáře na Ábíčku :-)

[1] sem nepočítám to skládání a rozkládání složených výrobků, které je potřeba ošetřit jinak

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Pavel Stárek avatar 22.9.2014 16:09 Pavel Stárek | skóre: 43 | blog: Tady bloguju já :-) | Kolín
Rozbalit Rozbalit vše Re: Sql primary key
No jde o to, že pokud budu třeba naskladňovat 10 pytlíků cukru a každý jednotlivý pytlík budu chtít mít v DB, tak EAN nemůžu použít jak PK (respektive můžu ho použít jak PK pro jeden druh pytlíku cukru od jednoho výrobce a pak to celé nějak provázat). Se zbytkem souhlas. Ale z principu věci by se neměli vyskytnout dva výrobky se stejným EANem. To by byl v obchoďácích pěkný bordel :-D
Kdo chce, hledá způsob; kdo nechce, hledá důvod.
xkucf03 avatar 22.9.2014 16:36 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
No jde o to, že pokud budu třeba naskladňovat 10 pytlíků cukru a každý jednotlivý pytlík budu chtít mít v DB, tak EAN nemůžu použít jak PK (respektive můžu ho použít jak PK pro jeden druh pytlíku cukru od jednoho výrobce a pak to celé nějak provázat).

Jde o to, jestli chci evidovat jednotlivé kusy, nebo mi stačí typ + množství. Pokud jsou ty kusy zaměnitelné (nemají sériová čísla atd.), tak stačí evidovat množství, případně je seskupit do nějakých várek (abych mohl dělat FIFO, LIFO…).

Ale z principu věci by se neměli vyskytnout dva výrobky se stejným EANem. To by byl v obchoďácích pěkný bordel

V tom případě by mělo být v pořádku použít EAN jako PK pro určitou entitu v databázi. Vím, že třeba v RČ je bordel, ale pokud tady bordel není, tak je to v pohodě.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9.2014 17:55 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Platí: Bordel je vždy ve všem, a pokud je v něčem náhodou pořádek, tak se dřív nebo později, spíš dřív, najde někdo kdo v tom udělá bordel a ty i když to máš v pořádku si v pr..li.

EAN je bordel jak každý jiný, někdo tam udělá chybu a ty to pak máš mimo systém, místo abys udělal jen „procesní“/„personální“ opatření a na pozadí dořešil chybu. Nebo budeš chtít mít Colu z cukrem a Colu s fruktózou a a jsi mimo, bo to má stejný EAN (si myslím) a takových změn specifikace bude roj. Výrobci se nechtějí přiznávat, ale zákazník potažmo obchodník je rozlišit chce.

OT: Není to tak dávno, nakupoval jsem a už nevím co to bylo (normální supermarket) a prodavačka na pokladně pípla, asi se jí něco ukázalo, bo hledala něco na výrobku a když jsem se ptal (mě takové věci vždycky s úsměvem zajímají), tak mi řekla, že mají stejné kódy na dvou výrobcích a musí to zadat ručně. Možná to byl zrovna tento „bordel“.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.9.2014 18:05 j
Rozbalit Rozbalit vše Re: Sql primary key
To nemusi bejt ani bordel ...

EAN muze (zcela koser) vypadat tak, ze ma vic znaku (ostatne, carovych kodu je cela hromada). Dalsi znaky slouzi (napriklad) prave k odliseni mnoztvi (muzes mit flasku koly 1/2litru, litr, 2 ...) jenze jejich system/snimac/... to neumi zpracovat.

Jinak trebas sklad kterej adminuju nema s vice vyrobky stejnyho EANu problem, da skladnikovi vybrat, ovsem ten problem nastane hned v dalsim kroce - vybere si zarucene blbe.
22.9.2014 18:14 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Ju, a právě proto nemůže být EAN PK.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
xkucf03 avatar 11.9.2014 22:55 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
id by melo byt pole, ktere nikdy nikde nefiguruje, neni nikde v aplikaci videt, uzivatel o nem vubec netusi a tak nema blby napady, a nemeni ho.

Měnit by se nemělo, ale figurovat klidně může. Když už ten identifikátor máme, tak ho můžeme používat, ne si ho jen střežit uvnitř databáze. Zrovna to osobní číslo je prostě ID, bezvýznamový identifikátor osoby v rámci organizace, nemá cenu vedle něj zavádět ještě jiný.

mas 5 dodavatelu, ti dodavaji jakejsi produkt a ty potrebujes v systemu sice odlisovat produkty tech 5ti dodavatelu, ale dal to uz je produkt jeden, s jednim EANem ...

Tak to je složený klíč (dodavatel, ean)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.9.2014 23:02 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key

Tak to je složený klíč (dodavatel, ean)

Tomu bych se vyhnul. Náhodou vznikne potřeba evidovat různé šarže jednoho výrobku se stejným EAN od stejného dodavatele a jsi v loji. Pro mne jsou dodavatel_id a ean jen dva atributy skladového zboží.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 11.9.2014 23:20 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

To jde o to, jestli ten EAN je pro nás ID. Pokud ano, tak mi přijde správné použít složený klíč (dodavatel, ean). Vycházel jsem z toho, že j psal:

ale dal to uz je produkt jeden, s jednim EANem ...

Pokud je dál EAN vyhovujícím identifikátorem, tak by měl být ten složený klíč OK.

Spíš mi přijde, že ho lidi nepoužívají kvůli pohodlnosti – radši spojují tabulky přes jedno ID než přes složený klíč (i když by to dávalo větší smysl).

Pokud identitu toho objektu tvoří i šarže, tak to bude (dodavatel, ean, šarže). Ale tam zase narážíme na to, že šarže závisí na EANu, takže by to chtělo nejspíš tabulku (id, ean, šarže) a odkazovat se na toto id. Na druhou stranu ta nová tabulka by mohla mít složený klíč, na který bychom se odkazovali místo id, takže by to vypadalo stejně… a tu novou tabulku bychom vlastně mohli zase zrušit, protože by nenesla žádnou užitečnou informaci… No tohle tady asi nevymyslíme, když není známé zadání a jen tak teoretizujeme. :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.9.2014 23:33 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Obvyklé zadání by mohlo být: Chci naskladnit zboží s určitým EAN od nějakého dodavatele, s nepovinnou šarží a expirací, s dalšími atributy. Obvyklým řešením je založení skladové karty s jedinečným id jako PK a jmenovanými atributy.

Dodnes vzpomínám, jak jsme řešili problém s rodným číslem (primárním klíčem) u člověka, který rodné číslo neměl. Architekt aplikace s tímto případem prostě nepočítal. Proto si hodně rozmyslím, než použiji PK z cizího zdroje.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 12.9.2014 09:05 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

jj, může být, ale už je to trochu jiné zadání – neevidujeme produkt, ale jakousi dávku, která nám odněkud přišla a má nějaké vlastnosti. A ty dávky si budeme číslovat podle toho, v jakém pořadí přišly.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2014 17:44 j
Rozbalit Rozbalit vše Re: Sql primary key
To je prave to, je videt ze s realitou ses jeste nepotkal. Proto to ID nesmi byt nikde videt natoz aby se nejak pouzivalo (jinak nez k definici vazeb). Protoze za tejden ti prijde odberatel, kterej ti rekne, ze on si nebude objednavat v EANech, ale v nejakych internich hasnumerech a ty si chte nechte musis ty jejich cisla nejak domastit do systemu a pridelit je prislusnym polozkam (at zijou markety). Samo je to okoreneno o to, ze si hodla objednavat v jinych jednotkach, nez v jakych ty to zbozi skladujes, takze jestli mas ve skladu pixly s barvou, trebas po 5kg, tak market si to bude misto na ks objednavat na litry ...

Lidi nicnerikajici ciselna id pouzivaji proto, ze se s realitou uz potkali, a vedi moc dobre, ze presne hodinu potom, co definitivne zadratujou do uid nejaky vyznam, si nekdo vzpomene, ze potrebuje jeste nejaky dalsi ...
xkucf03 avatar 12.9.2014 18:35 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Proto to ID nesmi byt nikde videt natoz aby se nejak pouzivalo (jinak nez k definici vazeb). Protoze za tejden ti prijde odberatel, kterej ti rekne, ze on si nebude objednavat v EANech, ale v nejakych internich hasnumerech a ty si chte nechte musis ty jejich cisla nejak domastit do systemu a pridelit je prislusnym polozkam (at zijou markety).

To je celkem běžná věc, že se eviduje „ID v externím systému XY“ a udržují se různé mapy. Ale opravdu nevidím důvod, proč náš PK utajovat před ostatními. Kdo chce, si podle něj klidně může objednávat a je to dobrá výchozí volba – pro něj to prostě bude „ID v externím systému“. A kdo si bude chtít objednávat podle svých ID, pro něj budeme udržovat mapu externích ID zase my.

Lidi nicnerikajici ciselna id pouzivaji proto, ze se s realitou uz potkali, a vedi moc dobre, ze presne hodinu potom, co definitivne zadratujou do uid nejaky vyznam, si nekdo vzpomene, ze potrebuje jeste nejaky dalsi ...

O jakém významu mluvíš? Někdo používá jako PK různé kódy typu xxx_yyy_zz a je schopný z toho na první pohled ledasco vyčíst. Ale tomuto přístupu nejsem vůbec nakloněn a nikde jsem ho tu nepropagoval. Už jenom proto, že je potřeba je přidělovat ručně a že to porušuje první normální formu.

Mluvil jsem o složeném PK. Ten někdy dává smysl a někdy je lepší se mu vyhnout, protože do něj časem přibude další sloupec. Ale někdy do něj z podstaty věci už nic přibýt nemůže – a pak je nepoužití složeného klíče otázka subjektivního pohodlí – což neříkám, že je úplně irelevantní argument – taky složené klíče nepoužívám zrovna moc často.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9.2014 18:18 j
Rozbalit Rozbalit vše Re: Sql primary key
Chjo ... co nechapes na tom, ze trebas pani u kasy je zvykla, ze ... cojavim mejdlo ma kod 1234 ... a pak zacnejs prodavat jiny mejdlo s jinejma parametrama => potrebujes ZAROVEN, aby mejdlo melo kod 1234, pochopitelne MUSIS zachovat i puvodni mejdlo (protoze 10 let historie min). Jiste, muzes pani u kasy vysvetlit, ze mejdlo bude 4567 ... a ona 80% lidi proda misto mejdla neco uplne jinyho.

Jakmile mas libovolny ID viditelny v systemu, tak to vede k tomu, ze to lidi nejak vyuzivaj, a to nasledne k tomu, ze chtej, aby to numero (nebo cokoli) bylo nejak formatovany, a pro jejich ucely nejaky ...

Z podstaty veci se zmeni vzdy a vsechno. Chces zcela konkretni priklad z konkretni aplikace? Takova z podstaty naprosto jednoznacna vec jako je DIC. I byval system tak jak je bezne navrzen tak, ze firma a dic je vazba 1:1 => proste v tabulce s firmou byl sloupecek dic. Jednoho krasneho dne se ovsem byrokrati rozhodli, ze dic je treba zmenit a voiala, pruser byl na svete. Ono je totiz treba zpracovavat doklady nejen dnesni, ale i vcerejsi, pripadne je treba udelat dobropis stavajicimu parnerovi, ale na puvodni dic ... a tak vyvojari domastili dalsi sloupecek s id, a tabulku se seznamem dic. Puvodni samozrejme z duvodu kompatibility zachovali.

A vysledek? 1/2 veci v systemu cte dic z tabulky, druha z policka. Policko se sice nejak updatuje pri zmene v tabulce, ale pokud nekdo napise dic primo do policka (ktere je stale viditelne) tak tam je proste neco jineho nez v tabulce => podle toho co kdo prave tiskne, tak na tom muze byt to ci ono.

Ted si predstav, ze bys DIC pouzil jako id firmy....
xkucf03 avatar 22.9.2014 20:14 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Chjo ... co nechapes na tom, ze trebas pani u kasy je zvykla, ze ... cojavim mejdlo ma kod 1234 ... a pak zacnejs prodavat jiny mejdlo s jinejma parametrama => potrebujes ZAROVEN, aby mejdlo melo kod 1234, pochopitelne MUSIS zachovat i puvodni mejdlo (protoze 10 let historie min). Jiste, muzes pani u kasy vysvetlit, ze mejdlo bude 4567 ... a ona 80% lidi proda misto mejdla neco uplne jinyho.

V tom případě je 1234 stále primárním klíčem – akorát jiné entity. Tato entita představuje určitou skupinu zboží. Má nastavenou aktuální položku a má i historii.

Jakmile mas libovolny ID viditelny v systemu, tak to vede k tomu, ze to lidi nejak vyuzivaj, a to nasledne k tomu, ze chtej, aby to numero (nebo cokoli) bylo nejak formatovany, a pro jejich ucely nejaky ...

Často jde o špatně navržené procesy. Vedle toho, že se modeluje databáze, je potřeba zmapovat současné procesy, navrhnout jejich přestavbu, vylepšení a následně tyto vylepšené procesy implementovat v IS (ne tam implementovat procesy, které se používaly za Rakouska-Uherska nebo v době psacích strojů a kopíráků).

Ono je totiz treba zpracovavat doklady nejen dnesni, ale i vcerejsi

Tohle je častá chyba. Účetní doklady nemůžou obsahovat odkaz na aktuální hodnotu – musí obsahovat přímo tuto hodnotu nebo odkaz na verzovanou tabulku, kde máme uvedeno, od kdy do kdy tato hodnota platila. Tohle se netýká zdaleka jen DIČ – jde hlavně o adresy nebo názvy společností.

a tak vyvojari domastili dalsi sloupecek s id, a tabulku se seznamem dic. Puvodni samozrejme z duvodu kompatibility zachovali. A vysledek? 1/2 veci v systemu cte dic z tabulky, druha z policka. Policko se sice nejak updatuje pri zmene v tabulce, ale pokud nekdo napise dic primo do policka (ktere je stale viditelne) tak tam je proste neco jineho nez v tabulce => podle toho co kdo prave tiskne, tak na tom muze byt to ci ono.

Za to já nemůžu, že tuhle změnu někdo implementoval blbě ;-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 22.9.2014 20:16 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

BTW: jeden můj komentář z roku 2010:

Tak zrovna 3NF je pro účetní doklady naprosto nevhodná, protože ty není možné zpětně v čase modifikovat

Mně to ale nepřijde jako něco v rozporu s normální formou. Údaj (adresa) na faktuře k nějakému datu je prostě jiný údaj než adresa v aktuálním adresáři firem. Řešit to odkazem, cizím klíčem, IMHO není lpění na normální formě ale obyčejná hloupost (odkazujeme se někam, kam bychom neměli).

možnost, že by se do tabulek přidala ještě dimenze času, která by říkala v jakém okamžiku byla daná adresa platná

Je to jedno z řešení. Druhou možností je mít jednu adresu pro každou fakturu – ani tak to nemusí být denormalizace dat – stačí se na to dívat tak, že adresa k 2010–01–07 11:28 je svébytný údaj a je to něco jiného než adresa (k jiné faktuře) k okamžiku 2010–01–07 11:35. Je to něco jako naměřené hodnoty třeba z teploměru – jednou jsme naměřili 10°C, za hodinu naměříme zase 10°C, ale taky to nebudeme řešit cizím klíčem na nějaký jeden záznam…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2014 17:51 Filip Jirsák
Rozbalit Rozbalit vše Re: Sql primary key
Osobní číslo bude unikátní identifikátor přesně do té doby, než se dvě firmy sloučí. To je právě problém těch přirozených unikátních identifikátorů, že přestanou být unikátní daleko dřív, než si kdokoli na začátku představoval.
xkucf03 avatar 12.9.2014 18:17 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Osobní číslo moc přirozený identifikátor není, ale hlavně, když se sloučí dvě firmy, tak je celkem jedno, jestli jsme tomu číslu říkali „osobní“ nebo třeba ID.

Stejně nebudeme chtít mít v systému dvě osoby se stejným osobním číslem1, takže část lidí budeme muset přečíslovat.

A pokud se v jiných systémech odkazujeme na osobní číslo nebo ID, máme problém tak jako tak. Pokud je to osobní číslo, tak to se u některých lidí změní. A pokud je to jiné ID, tak u něj můžou stejně tak nastat konflikty (protože ta druhá firma přiřadila stejná ID jiným lidem) a ve sloučeném systému je rovněž budeš muset přečíslovat nebo tam mít nežádoucí duplicity a jako PK používat ještě něco jiného.

Jediným řešením by bylo všude používat globálně unikátní identifikátory, třeba 123@osoba.firma-a.tld a pak bys v pohodě mohl sloučit dvě firmy a mít v nich zaměstnance:

123@osoba.firma-a.tld
123@osoba.firma-b.tld
123@osoba.firma-c.tld

Což by byli tři různí lidé.

Ale stejně by se mohlo stát, že by jeden člověk pracoval v obou firmách na částečný úvazek, nebo byl v té druhé firmě bývalým zaměstnancem rovněž evidovaným v systému :-) A pak bys měl pro změnu jednu fyzickou osobu v systému víckrát.

[1] leda že by ten systém podporoval více organizačních jednotek s více řadami osobních čísel – ale pak by to pro nás byl od začátku složený klíč (organizační_jednotka, osobní_číslo)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.9.2014 21:22 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Neměnnost není podmínkou. Podmínkou je jen jedinečnost.
Josef Kufner avatar 11.9.2014 22:23 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Sql primary key
V okamžiku, kdy komunikuješ s okolním světem, tak nejsi schopen propagovat své změny, takže i ta neměnnost je potřeba.
Hello world ! Segmentation fault (core dumped)
13.9.2014 21:28 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
A kdy by bylo třeba propagovat změny ven z databáze?

Pokud používám jako PK například rodné číslo (ne, že bych to obhajoval), tak pokud jsem tu hodnotu změnil, tak mám úplně jiné problémy, než aktualizace této hodnoty v databázi.

A pokud používám nějaké sintetické id, tak jsem hlupák, že ho prozrazuji ven.
13.9.2014 22:34 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Vždyť i EAN je pro výrobce syntetickým ID. Pro příjemce je cizím klíčem a neměl by ho používat jako primární. Pro rodné číslo platí totéž - navíc "výrobce" (tedy ani to číslo) v mnoha případech neexistuje a proto se jako primární klíč použít nedá. Ovšem zdravotním pojišťovnám to asi nevysvětlíme.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
18.9.2014 21:01 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Nejsem si jist, na co reaguješ. Souhlasíš, nebo máš vůči mému tvrzení nějaké výhrady?
18.9.2014 21:17 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
A pokud používám nějaké sintetické id, tak jsem hlupák, že ho prozrazuji ven.
EAN je syntetickým ID stejně jako rodné číslo nebo ISBN. Pro výrobce může být primárním klíčem. Tento údaj je propagován ven. Příjemce by ho však jako primární klíč rozhodně používat neměl.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
18.9.2014 22:23 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
A to je rozhodně chyba.
19.9.2014 06:54 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Jak potom řešíš situace, kdy člověk nemá rodné číslo, výrobek nemá EAN a kniha nemá ISBN? Nahrazuješ to vymyšlenými čísly jako v našem IS? Pěkná hloupost.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
19.9.2014 11:57 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Nemáte-li identifikátor, bude vám přidělen.

Abychom si rozuměli, já tu zastávám tyto teze:
  1. PK musí být jedinečný v rámci databáze. Nemusí být neměnný, databáze tuto vlastnost nevyžaduje.
  2. Pokud použiji jako PK nějaký reálný údaj ze záznamu, například EAN, ISBN, rodné číslo - osobně bych to nedělal, ale spíše z výkonostních důvodů.
  3. Používám-li jako PK vlastní generované číslo (což preferuji), tak použít ho zároveň jako identifikátor i pro vnější svět nepovažuji za dobrý nápad, právě proto, že to svazuje refactoring databáze. Defakto se dostáváme do předchozího bodu, jen z jiného směru.
Jednou větou: PK != Identifikátor pro vnější svět
pavlix avatar 19.9.2014 12:15 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Sql primary key
Nemusí být neměnný, databáze tuto vlastnost nevyžaduje.
Slušný databázový systém sice nabízí možnost updatovat klíč napříč tabulkami, ale jen do té doby, dokud jsou ty tabulky skutečně v rámci jedné databáze.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
19.9.2014 13:38 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Dyť jo, ne?
xkucf03 avatar 20.9.2014 10:45 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
použít ho zároveň jako identifikátor i pro vnější svět nepovažuji za dobrý nápad, právě proto, že to svazuje refactoring databáze

Jak tedy řešíš situaci, kdy chceš provázat dva systémy? Jak se odkazuješ na entity z druhého systému? Vytvoříš si vedle PK ještě jeden unikátní sloupec určený pro externí systémy jako veřejný identifikátor?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9.2014 15:03 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Záleží hodně na tom, jak moc robusní bych ten systém chtěl mět. Pravděpodobně v mnoha případech ano.

Rád bych zdůraznil, že se tu bavím na akademické úrovni. V praxi se samozřejmě člověk sníží k různým prasárničkám, protože optimalizace, výkon, lenost.

Můj příspěvek mířil k tomu, že tu mnozí zaměňují smysl primárního klíče pro databázi s unikátním záznamem na úrovni aplikace kterým často PK může být zneužita.
22.9.2014 15:12 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
zut!

oprava

"smysl primárního klíče pro databázi s neměným identifikátorem záznamu na úrovni aplikace "
xkucf03 avatar 22.9.2014 15:57 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Pravděpodobně v mnoha případech ano.

A co je ten důvod? Nechceš vyzradit PK, považuješ ho za tajný údaj? Nebo ho chceš mít možnost měnit? Byl by problém tam ten sloupec pro „veřejné ID“ přidat dodatečně a do té doby používat místo dvou sloupců jeden?

Někdo může chtít utajit třeba počet svých zakázek nebo uživatelů, tak by jako „veřejné ID“ mohl používat nějakou nesouvislou řadu nebo začít na nějakém vysokém náhodném čísle s náhodným skokem. Ale tak jako tak musíš zajistit unikátnost – takže proč to unikátní číslo nepoužít rovnou jako interní PK? Taky jsem se setkal s tím, že někdo používal UUID, to už je vůbec prasárna – když se nejedná o distribuovaný systém, kde by ty ID vznikaly na více místech … navíc je tu hypotetická (nebo i reálná) možnost kolize.

Nebo můžeš chtít chránit soukromí uživatelů, přidělovat jim nějaké dočasné identifikátory, jedna osoba může mít více veřejných identifikátorů, třeba podle toho, s jakým externím systémem komunikuje atd. Takže pak nejde spárovat tu identitu napříč různými systémy (resp. můžeš to udělat leda ty, ne ty externí aplikace). Tohle i v jednom systému používám…

Ale myslím, že by k tomu měl být nějaký dobrý důvod – nedělal bych to automaticky.

Např. metodika extrémního programování říká, že bys měl programovat jen to, co je v danou chvíli nezbytné. Určitá předvídavost do budoucna je dobrá, ale nic se nesmí přehánět a člověk by se neměl utopit v úvahách „co by kdyby“ a implementovat milion věcí, které by mohly být potřeba (ale s největší pravděpodobností nebudou). Při rozhodování se mj. ptám: kolik kódu budu muset zahodit, když se to v budoucnu rozhodnu přepsat robustnějším způsobem? A když mi vyjde, že minimum a že s tím nebudou velké těžkostí, tak je lepší to udělat tím jednodušším přímočařejším způsobem.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9.2014 18:12 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Obecným důvodem je pravidlo, že čím více podrobností svět ví o mé implementaci, tím více práce mi to v budoucnosti přinese.

Pokud je možné, veřejné ID doimplementovat dodatečně, je to šikovná volba. Mě vadilo spíše to, když to lidé nejsou schopni rozlišovat a vznikaj pak takové pověsti, jako že PK musí být neměnné.
21.9.2014 23:35 Logik
Rozbalit Rozbalit vše Re: Sql primary key
1) Ano, ale splňuje všechny potřebné informace pro vnější identifikátor. Není tedy důvod kvůli tomu zavádět identifikátory dva. Neměnnost sice nepožaduje databáze, ale je to velmi vítaná vlastnost (už pro ten vnější id).

3) Pokud se potřebuješ odkazovat zvnějšku do databáze, odkazuješ se na nějaké entity. Jakýkoli refaktoring databáze tedy musí tyto entity musí zachovat. Ať jim použiješ jakýkoli identifikátor, ten musí v db zůstat a z normálních forem vyplývá, že by měl zůstat unikátní (pokud se refaktoringem zneunikátní, tak je to důvod pro rozdělení tabulky). Tedy není důvod, proč by i po refaktoringu neměl být tento údaj primárním klíčem.

Naopak právě klíčová vlastnost primárního klíče - že nikdy není potřeba měnit - tvoří umělý primární klíč výtečným identifikátorem pro vnější svět. A naopak i právě existence takového identifikátoru (který je potřeba v podstatě vždy, např. pro logování), je dalším důvodem, proč zakládat umělé neměnné primární klíče.
22.9.2014 15:02 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Zaměňuješ příčinu a následek.

1/ Databáze nevyžaduje neměnnost. Tečka!

Pokud já od aplikace vyžaduju, aby záznam měl neměnný identifikátor, tak mám více možností, jak toho dosáhnout. Jedním z nich je, že k databázovém PK přiřadím ještě povinnost, že musí být neměnný. Fajn, je to možnost, a často se to tak dělá, ale dá se to dělat i jinak.

A spor byl hlavně v tom, zda PK z principu vyžaduje neměnnost.

3/ To je jen důsledek tvého zaměnění příčiny a následku. V mém případě refaktoring id zachovat nemusí, protože jej ze zásady nezveřejňuji.
24.9.2014 11:17 logik
Rozbalit Rozbalit vše Re: Sql primary key
1] Databáze nevyžaduje normální formu. Znamená to, že je špatně normální formy požadovat? Spor byl o to, jestli je vhodné nebo ne požadovat po PK neměnnost, nikoli to, co požaduje DB.

3) Nepochopil - naopak Ty zaměňuješ příčinu a následek. Příčina je to, že se někdo potřebuje na Tvoje data odkazovat. Následek je, že musíš mít v db identifikátor, nějaké ID, pomocí kterého se na danou entitu odkazuje. Tento identifikátor musí splňovat požadavky PK a navíc být neměnný. Ta otázka stojí - může či má být to id PK?

Každý refaktoring databáze, který uděláš, tak musí v databázi zachovat tabulku, kde budou uchovány tyto identifikátory. Jinak bys porušil vazbu s vnějším světem (musíš být schopen ten identifikátor i rychle vyhledat). Takže každý refaktoring databáze musí z principu zachovat to, že identifikátor pro vnější svět zachovává vlastnosti PK. Proto argument, že zveřejnění PK zabraňuje refaktoringu prostě není pravdivé - stejnému refaktoringu zabraňuje už samotný požadavek na to, že na data má být odkazováno z vnějšku - a proto není důvod, proč dané ID nepoužít jako PK.

Vzhledem k tomu, že použití toho ID jako PK má benefity, tak je lepší ho použít.

--

Obávám se, že Tvá nechuť k zveřejňování PK plyne z faktu, že dochází k zneužívání těchto ID k odkazování na jiné entity, než ve skutečnosti reprezentují. Tam je pak opravdu při refaktoringu problém (odkazuji se na ID výrobku a chci ve skutečnosti odkazovat na šarži). To je ale špatně, ať už se dané ID použije jako PK či nikoli. V případě, že odkazovatel nemůže tu chybu opravit, pak může být opravdu řešení bez ID vhodnější. V tu chvíli je ale dané ID nikoli můj identifikátor, ale identifikátor odkazovatele, tedy významové ID a tedy od začátku nesplňuje požadavek pro PK.

24.9.2014 13:43 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
1/ Databáze vyžaduje normální formu, jinak nefunguje dobře. Nemáš-li PK neměnné, databáze funguje dobře.

3/ Jenže vnější svět se nemá co odkazova na PK, od toho není. Má se odkazovat na ID. Že je někdy ID eq PK, neimplikuje, že je ID = PK.

-- Co se mé nechuti týče, můžeš mět pravdu. A také jsem purista.

xkucf03 avatar 24.9.2014 17:06 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
1) Normální formy jsou doporučení. Návrhář datového modelu by je měl znát, měl by navrhnout datový model normalizovaný a v případě, že je k tomu dobrý důvod, může databázi denormalizovat.

Normální formy se běžně porušují (teď nemluvím o porušování z neznalosti) a databáze fungují pořád stejně dobře. Akorát někdy řeší jinou/náročnější úlohu (třeba aktualizování víc hodnot nebo práci s neatomickými hodnotami), ale pracují pořád stejně dobře.

3) Ve většině případů nemám problém se zveřejněním PK a jeho používáním pro vytvoření vazby v jiných systémech. Pokud v tom problém je, tak spíš z důvodu ochrany soukromí nebo utajení některých skutečností.

Považuji za nesmyslné vedle PK vytvářet automaticky ještě další sloupec s nějakým veřejným identifikátorem. Ve většině případů to bude zbytečná práce, zbytečná složitost, která ti akorát přidělá komplikace.

V budoucnu můžeš přidat další sloupec, nakopírovat do něj původní hodnoty a PK nechat jít jinou cestou (bude se generovat jinak, než to druhé ID), ale do té doby to může být jeden sloupec.

Ano, můžeš mít tolik dat, že přidání dalšího sloupce by bylo náročné... takže by to svádělo k tomu, udělat ho tam radši předem. Jenže to není řešení - většinou ten druhý sloupec nebude potřeba vůbec a jindy bys jich zase potřeboval víc, protože v jednom externím systému chceš mít takové identifikátory a v jiném zase jiné - tudíž bys potřeboval dva sloupce. Navrhnout ten model hned na začátku tak, aby vyhověl všem budoucím požadavkům prakticky nejde - takže je lepší zase tolik nepředbíhat a neimplementovat všechno možné.

Taky se ti klidně může stát, že to jedno ID budeš chtít měnit - PK bys nezměnil, sekundární ID změníš... ale to je taky chyba, protože všude kolem (logy, papírové doklady, staré systémy atd.) máš to původní nezměněné ID. Takže potřebuješ uchovávat historii - v tom případě ti nestačí jeden sloupeček a spíš potřebuješ mít další tabulku, kde bude, odkdy dokdy bylo dané ID pro určitý PK přiřazené.

A jak jsem psal, můžeš chtít mít různé veřejné ID pro různé externí systémy, pro tu samou entitu (PK). Tudíž potřebuješ další tabulku, ne další sloupec.

Tuhle tabulku si tam můžeš doplnit kdykoli později - a do té doby můžeš vesele používat PK pro vazby z jiných systémů.

A mimochodem, ta nová tabulka je entita a to veřejné ID je jejím primárním klíčem (může být složený s datem od, do a identifikací - FK - externího systému). Takže jsi zase tam, kde jsi nechtěl být - poskytuješ ven PK ;-)
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
24.9.2014 20:07 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Souhlasím. Proti tomu jsem ostatně nebrojil,
22.9.2014 10:48 j
Rozbalit Rozbalit vše Re: Sql primary key
" Nemusí být neměnný, databáze tuto vlastnost nevyžaduje. "

Jen do chvile, nez se dostanes do realnyho sveta. Navic bych fakt chtel videt, jak zaridis konzistetni zmenu id napric stovkama tabulek databaze.
22.9.2014 14:47 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Většina databází umí ... ON UPDATE CASCADE.

Pokud to databáze neumí, tak pochopitelně má věta neplatí. Jenže tak nějak předpokládám, že se bavíme o nějakém průniku "normálních" databází.
22.9.2014 18:40 j
Rozbalit Rozbalit vše Re: Sql primary key
Vetsina databazi umi lecos, vetsina aplikaci z toho nevyuziva ani promile. Nemluve o tom, ze pak chci videt, jak budes resit situaci, ze nekdo zmeni ID zaznamu a nekdo jinej chce prave ulozit jeho modifikovanou verzi, kterou si nacet jeste pred zmenou => posila update s puvodnim ID, a rozhodne nechce prijit o svy zmeny.
22.9.2014 18:53 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Moment! Kde dotyčný vzal to původní ID? Bavme se o jednom, nebo o druhém. Ale nemíchat!
26.9.2014 09:46 j
Rozbalit Rozbalit vše Re: Sql primary key
Michas tady ty ...

Pokud neco v databazi delam, deje se zhruba nasledujici:

selec id, jmeno, * from ...

--- tady probehne modifikace pole jmeno

update ... set jmeno = where id =

Ted si predstav nasledujici (ty ses ten, kdo propaguje zmenu IDcek):

selec id, jmeno, * from ...

select id --- tuhle se nekdo rozhodne, ze zmeni id update ...

--- tady probehne modifikace pole jmeno

update ... set jmeno = where id = --- a sme vprdeli
xkucf03 avatar 26.9.2014 10:10 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Já tedy změnu IDček nepropaguji, ale: slyšel jsi někdy o transakcích?
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
pavlix avatar 26.9.2014 10:11 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Sql primary key
+1
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
1.10.2014 19:40 j
Rozbalit Rozbalit vše Re: Sql primary key
O transakcich si zjevne nic neslysel ty, protoze transakce tenhle problem vubec neresi.

Transakce mi zaridi jedine to, ze se povede bud vse nebo nic. tzn pokud aktualizuju vic tabulek najednou, potrebuju zaridit, ze se aktualizujou vsechny a ne ze to jednu updatne a druhou ne. Pak to dam do transakce.

V tomhle pripade mi transakce zbuchne, a je jedno jestli na update jedinyho pole nebo 150ti poli, jednoduse zaznam, kterymu nejakej magor zmenil ID, protoze ID se menit prece muze, nelze aktualizovat, a uzivatel pude nejspis adminovi rozbit hubu, protoze prave prisel o 1/2 hodinu editaci.

Ano, muzu upravovany zaznam locknout, a na hodinu, dve ci tri ... zastavit provoz systemu. Kdybych mel locknout vsechno, na co prijde select, v ocekavani, ze mozna prijde update, tak mam za 10s zamcenou celou databazi.

Ty totiz zjevne vubec netusis, ze mezi tim moh nekdo zmenit jina pole stejneho zaznamu, coz transakce samozrejme taky vubec neresi. Stejne jako neresi to, ze nekdo jiny mohl zmenit dokonce stejne pole jmeno.

Abychom si rozuměli, já tu zastávám tyto teze:

PK musí být jedinečný v rámci databáze. Nemusí být neměnný, databáze tuto vlastnost nevyžaduje.

Ne, databaze to skutencne nevyzaduje, vyzaduje to jen realita.
1.10.2014 20:10 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
O transakcich si zjevne nic neslysel ty, protoze transakce tenhle problem vubec neresi.
Mějme dvě situace:

1. - Vytáhneme si záznam podle ID, upravíme položku Name - Někdo jiný změní hodnotu ID - pokusíme se uložit záznam, který adresujeme podle ID

nebo:

2. - Vytáhneme si záznam podle ID, upravíme položku Name - Někdo jiný změní hodnotu položky Name - pokusíme se uložit záznam, který adresujeme podle ID

Vidíš v tom problém? A vidíš v tom rozdíl? Řeší ten problém neměnnost ID? Řeší ten problém Transakce?

Ne, databaze to skutencne nevyzaduje, vyzaduje to jen realita.
Silná slova. Mě realita naučila, že je dobré přesně rozumět věcem.
1.10.2014 23:19 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Ano, máš pravdu - případ 2 je principiálně neřešitelný a je to problém.

Nechápu ale, jak z toho plyne, že bych si měl zadělávat na další problémy tím, že kromě tohoto problémového scénáře dovolím volatilitou IDček i scénář jedna, který bych mohl eliminovat.
1.10.2014 23:56 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Protože případ 2 je nejenom řešitelný, a není to problém, ale navíc je to jen jiná verze případu číslo 1.

A v praxi se oba případy řeší tak, že se ignorují. Případ 1 tím, že se prostě zakáže měnit PK, a případ 2 tím, že se řekne, "hmm, smůla".
1.10.2014 23:59 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
V praxi = většina, jsou samozřejmě výjimky.
2.10.2014 14:40 logik
Rozbalit Rozbalit vše Re: Sql primary key
1) Případ 2 neřešitelný rozhodně JE - prostě nelze algoritmicky nijak rozhodnout, která z provedených úprav atributu je správná a tak každé možné řešení je zatíženo potenciální chybou. Asi nejlepší možná reakce je se uživatele zeptat na řešení, ovšem jednak ne každá editace dat je interaktivní, jednak to není řešení, pouze přesunutí rozhodnutí z kódu na někoho jiného (uživatele).

2) Řešení případu jedna tím, že zakážu měnit PK není řešení problému, ale jeho profilaxe. Protože je to profilaxe velmi účinná, tak je dobré ji dělat, pokud neexistují velmi silné důvody proti - a ty tady zatím nikdo nepředložil.
2.10.2014 16:47 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Když myslíš.

Já si z dovolením budu brát příklad z těch, kteří ten problém řeší, Wikipedia, Hibernate, atd.
2.10.2014 17:03 logik
Rozbalit Rozbalit vše Re: Sql primary key
Až na to že to neřeší, protože to z principu vyřešit nelze. Pokud tvrdíš, že lze, tak odpověz na otázku, jaký má být stav databáze s jednou řádkou:

ID=1 NAME='Jan'

do které přijdou najednou dva updaty UPDATE table SET NAME = 'Petr' WHERE id = 1 a UPDATE table SET NAME = 'Jan' WHERE id = 1

Jo, může tam být nějaký transaction repeater, který bude transakce opakovat tak dlouho, dokud neprojdou, to ovšem jaksi není řešení, ale pouze heuristika, která většinou dopadne dobře. Žádný sebeinteligentnější transaction repeater totiž není schopen zodpovědět, jak se daná osoba jmenuje.
8.10.2014 17:27 Kolemjdoucí
Rozbalit Rozbalit vše Re: Sql primary key
Hibernate to fakt řeší. A Wikipedie to dělá taky, si to zkus, když dáš editovat článek, který mezitím stihne editovat někdo jiný.

Sice to tady rozebíráš moc hezky, ale ve skutečnosti to tak není. Se s tím smiř.
8.10.2014 17:28 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
To je snad jasné, ne?
9.10.2014 00:08 fean
Rozbalit Rozbalit vše Re: Sql primary key
Co je jasné? Že to z principu vyřešit nelze?
9.10.2014 00:33 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Ale ne, ten problém samozřejmě problémem není, maximálně malou komplikací. Myslel jsem tu @Logikovo otázku.
9.10.2014 11:19 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Logik položil nějakou otázku? Kde?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
9.10.2014 11:48 logik
Rozbalit Rozbalit vše Re: Sql primary key
A jaká je tedy odpověď?
9.10.2014 14:27 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Tak nejdříve je nutné opravit zadání. Protože se nemůže stát, aby nějaké dva updaty přišli _najednout_.

Ale předpokládejme, pro cíl diskuse (i když se už strácím, o čem mluvíš), že máš na mysli, že přijdou hned za sebou, a ten druhý klient neví, o tom prvním. Tudíž výsledek bude, že ten druhý záznam bez mrknutí oka přepíše ten první.

Můžu vědět, co tím chceš dokázat?
9.10.2014 16:18 logik
Rozbalit Rozbalit vše Re: Sql primary key
Zaprve mohou přijít ve stejném čase - např. skrze dvě různá síťová rozhraní (nebo na dva různé aplikační servery při replikaci atd...). Ale to je detail.

Podstatné je to, že i když jeden přijde později, neznamená, že je správný. Úprava dat na provedená na základě neplatných vstupních dat je z principu špatně a ty na serveru nemáš šanci vědět, jestli ta úprava byla dělána s vědomím správných dat (tedy je správně, akorát to na serveru nemáš šanci zjistit), nebo bez (pak je prostě špatně).

Jediné, co v takové situaci na serveru můžeš zjistit je to, že akce uživatele vychází z neplatných dat. Lépe napsané aplikace to detekují a nějak na to reagují. Hůře napsané aplikace použíjí bezmyšlenkově algoritmus, který jsi výše popsal a který vede ke ztrátě dat, pokud náhodou dorazí jako druhá editace editace od A, který se nedozvěděl o mezitím provedené opravě od B.

Tvůj algoritmus tedy nic neřeší, pouze ignoruje možnost vzniku chyby. Neříkám, že to není někdy dostačujcí strategie, ale rozhodně to není řešení zmíněného problému.
9.10.2014 17:09 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Hmm, jaký algoritmus? Já někde uváděl nějaký algoritmus? A proč mi tady defakto opakuješ to, co jsem ti o pár příspěvků víše vysvětloval já tobě?

Já to vzdávám, toto už není předávání zkušeností, toto je trapné.
9.10.2014 17:47 logik
Rozbalit Rozbalit vše Re: Sql primary key
Hmm, jaký algoritmus? Já někde uváděl nějaký algoritmus?
Ano, uváděl:
Tudíž výsledek bude, že ten druhý záznam bez mrknutí oka přepíše ten první.
-----
A proč mi tady defakto opakuješ to, co jsem ti o pár příspěvků víše vysvětloval já tobě?
Ne, o pár příspěvků výše :-) jsi tvrdil, že to vlastně není problém:
Protože případ 2 je nejenom řešitelný, a není to problém, ale navíc je to jen jiná verze případu číslo 1.
(ten konec té věty mimochodem také není pravda, protože případ číslo 1 řešitelný je logováním změn ID za předpokladu, že nepovoluji znovuužití ID, zatímco případ číslo 2 principálně řešitelný není).

A tvrdils, že jestli to problém je, tak že je řešitelný a řešený:
Já si z dovolením budu brát příklad z těch, kteří ten problém řeší, Wikipedia, Hibernate, atd.
Přitom já jsem doložil, že problém (algoritmicky) řešitelný být nemůže, tedy že pokud chceme zamezit ztrátě dat, tak je třeba rozhodnutí obsluhy programu.

-----

Takže ano, je trapné, když každou chvíli tvrdíš něco jiného.
9.10.2014 18:15 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
To ale není algoritmus, to je popis co se bude dít!

a tak dále, a tak dále...

Obávám se, že zřejmě každý znás užíváme zcela jinou logiku. Toto je nad moje schopnosti.
9.10.2014 18:28 Kolemjdoucí
Rozbalit Rozbalit vše Re: Sql primary key
Škoda. Byla sranda vás dva sledovat.

10.10.2014 17:44 logik
Rozbalit Rozbalit vše Re: Sql primary key
Moje otázka byla, jaký má být stav databáze když přijdou dva konkurenční dotazy. Je úplně jedno, jesti to nazveš "algoritmus" nebo "popis toho, co se bude dít", fakt je, že to, co říkáš že se má stát, může vést ke ztrátě dat a tedy uvedený postup kroků není řešením problému.

Takže jsi doložil, že ten problém řešit neumíš, což není nic divného, protože on řešení nemá.

10.10.2014 20:01 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Hezký pokus. Ale už jsem se poučil: DNFTT.
xkucf03 avatar 2.10.2014 00:39 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Transakce tenhle případ:

update ... set jmeno = where id = --- a sme vprdeli

právě řeší – schválně jsem tam odkázal zamykání FOR UPDATE. Při SELECTu si zamkneš záznamy a díky ACID transakci nepůjde změnit ID záznamu, se kterým pracuje jiná transakce. Takže k té chybě, kterou jsi popisoval nedojde.

Pak je ještě jiná strategie – optimistické zamykání – záznamy nezamykáš, ale verzuješ je (přes číslo verze nebo třeba čas poslední aktualizace) a nedovolíš přepsání záznamu, u kterého se změnila během tvojí editace verze. Program může nabídnout třeba diff a ruční sloučení změn nebo prostě ohlásit chybu. Ale tak jako tak nesmí dojít k tomu, že by sis přepsal data u jiného záznamu kvůli tomu, že někdo změnil/prohodil IDčka.

Ten tebou popsaný scénář („a sme vprdeli“) se v dobře napsaném programu odehrát nemůže a to bez ohledu na to, zda změnu PK připustíme nebo ne.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 11:19 Filip Jirsák
Rozbalit Rozbalit vše Re: Sql primary key
Transakce tenhle případ obecně řeší jedině tehdy, pokud se použije největší izolace transakcí, tedy nějaký způsob jejich řazení za sebou. Často se ale používá nějaká nižší úroveň izolace, a tam už to takhle obecně neplatí – i při použití transakcí se může stát, že se vyhodnotí podmínky a hodnoty update, ale než dojde ke změně, jiná transakce ten záznam změní.
2.10.2014 14:41 logik
Rozbalit Rozbalit vše Re: Sql primary key
Transakce a zamykání toto vůbec nemusí řešit, protože ty jaksi vyžadují, aby SELECT a INSERT proběhl v rámci jedné akce. Což např. ve většině aplikací komunikujících s uživatelem neplatí.
8.10.2014 17:31 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Transakce lze chápat i šířeji, nejenom jako BEGIN - COMMIT. V praxi to funguje docela hezky.
9.10.2014 11:52 logik
Rozbalit Rozbalit vše Re: Sql primary key
Jo, takže kvůli tomu, abys moh pro nějakou hypotetickou možnost o něco málo snažšího refaktorignu databáze měnit idčka, tak budeš implementovat vlastní transakční logiku?

Říká Ti něco předčasná optimalizace?
9.10.2014 14:28 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
To samozřejmě nebudu. Jak si na to přišel, že bych něco takového chtěl dělat?
9.10.2014 16:04 logik
Rozbalit Rozbalit vše Re: Sql primary key
Nu pokud chápeš transakce šířeji než jen BEGIN - COMMIT v databázi, tak protože drtivá většina DB takové transakce neumožňuje, tak Ti nezbyde, než je implementovat sám (popř. s využitím nějaké knihovny - ale to nic nemění na tom, že to bude hromada práce navíc, která má smysl, jen pokud ušetří přinejmenšm stejnou hromadu práce).
9.10.2014 17:06 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Tak nějak. A?
9.10.2014 17:49 logik
Rozbalit Rozbalit vše Re: Sql primary key
A? No že věnuješ spoustu práce kvůli dosažení vlastnosti, která je pro drtivou většinu aplikací nepotřebná a proto je to zbytečná práce.

Daleko efektivnější je v případě potřeby upravit tu jednu aplikaci, ve které opravdu bude třeba s IDčky manipulovat.

Proto tedy Tvoje teze mezi "best practicies" nepatří.
22.9.2014 19:18 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Psal jsi, že ID nesmí nikde jinde figurovat. Tedy nesmí opustit databázi ani ho nikdo nesmí změnit.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
22.9.2014 20:25 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Psal jsem, že ID by němělo opustit databázi. Měnit ho mohu. Dotyčný pustil ID z databáze ven, a pak se diví.
22.9.2014 20:32 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Jak mohu změnit ID, když neznám to původní? Pokud aplikaci k tomu ID nedám přístup, tak ho přece změnit nemůže.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
22.9.2014 20:42 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Ale může.
22.9.2014 21:00 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Když mu nedám právo modifikace, tak nemůže.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 01:17 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Právo má. Jen nesmí ID opustit databázi. Hele, co je na tom tak těžkého pochopit?
23.9.2014 07:09 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Slyšel jsi už někdy něco o grantech?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 14:38 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Samozřejmě. Jak to souvisí s tématem?
23.9.2014 15:58 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Viz výše.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 16:19 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Téma, případně toto.
23.9.2014 16:53 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Jestliže ID nesmí opustit databázi, tak ho ani aplikace nevidí. Pokud má aplikace zakázáno modifikovat ID v databázi, tak ho nezmodifikuje ani kdyby se rozkrájela. Čemu na tom nerozumíš?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 20:38 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Té implikaci.

Aplikace nevidí ID !eq aplikace má zakázáno modifikovat ID.

Celé tohle vlákno je o tom, že se míchají dvě věci, které spolu principielně nesouvisí a ty tu smícháš dvě jiné. Tak ti teda dík!
23.9.2014 21:02 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Když aplikaci zakáži přístup k ID v databázi, tak ho nevidí a ani ho nemůže modifikovat. Jak chceš modifikovat ID, pokud ho nevidíš? Jako že zakážeš read a povolíš update? Spíš naopak zakáži modifikaci ID, ale povolím jeho čtení.

Dej sem ukázku.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 21:41 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
UPDATE t SET id = id + 1
23.9.2014 21:47 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Když však zakážu modifikaci, tak se ti to nepodaří.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
23.9.2014 22:40 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
No, to se skutečně nepodaří. A?
24.9.2014 07:12 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Pokud by se ti to podařilo, komu bys tím prospěl?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
24.9.2014 13:45 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Nerozumím tomu, jak otázka souvisí s tématem?
24.9.2014 11:31 logik
Rozbalit Rozbalit vše Re: Sql primary key
Jo - takže Tvoje řešení vede k tomu, že budeš mít v DB sloupec, který bude sloužit k tomu, abys když chceš, mohl udělat UPDATE t SET id = id + 1.

K čemu tam ten sloupec je? Když požádavek vnějšího světa mimo databázi stejně požaduje existenci dalšího neměnného identifikátoru splňujícím vlastnosti PK.

---

Zdá se mi, že o databázi uvažuješ jako o něčem zcela abstraktním. To databáze právě ale vůbec není. Ač jsou to relace, ve výsledku to není nic jiného, než popis nějakých objektů, které je třeba mj. nějak identifikovat. Požadavky na identifikaci objektu pak z definice splňují vlastnosti PK.

Jakýkoli refaktoring, který poruší vlastnosti tohoto identifikátoru jako PK pak nutně musí porušit i zaznamenanou informaci - proto pokud je návrh dobrý (tj. opravdu zachycuje to co má), tak žádná dobře provedená změna struktury DB neporuší schopnost identifikátoru býti PK. Proto není problém, když ten identifikátor bude PK - a zůstávají jen výhody, které plynou z toho, že mám dvě různé identifikace objektů, které musím navzájem překládat (a uchovávat historii změn jednoho či druhého identifikátoru, abych dohledal histori atd. atd.)
24.9.2014 14:01 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Na jiném místě jsem přiznal, že můj pohled je zcela akademický. Jediný problém, který mám, je ten, že někteří lidé zaměňují PK za ID.
  • PK slouží k tomu, aby ostatní objekty databáze věděli, ke komu patří => unikátnost.
  • ID slouží pro snadnou jednoznačnou identifikaci objektu => neměnnost.
PK je nutné. ID se dá často nahradit podmínkou: WHERE name=pepa surname=dvořák V mnoha aplikacích stačí, když je PK neměnné po dobu transakce.

Ne vždy je třeba mět pro záznam identifikátor, který bude mět tak přísnou podmínku, že je neměnnej na věky věků. Ano, někdy je to třeba, a pokud se na to zneužije PK, fajn. Ale nelze principielně tvrdit, že je to to samé.

Já nemám problém s tím, že se PK prohlásí zároveň za ID, čistě z praktických důvodů. Mám problém s lidmy, kteří nejsou schopni vidět rozdíl.
xkucf03 avatar 24.9.2014 17:13 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
PK => unikátnost, ID => neměnnost?

K čemu ti bude změna PK, když je to jen interní identifikátor pro vazby uvnitř databáze? A k čemu ti bude neměnné ID, když není unikátní a najdeš podle něj víc záznamů? Já se z toho externího systému přece potřebuji odkázat na jeden konkrétní záznam.

Pokud píšeš, že ID slouží pro snadnou jednoznačnou identifikaci objektu, tak by přece ID mělo být taky unikátní, ne?

Naopak interní PK, který nikde jinde nefiguruje, klidně změnit můžeš (kaskádový UPDATE), ale co z toho?
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
24.9.2014 20:09 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Moje chyba. U ID pravděpodobně opravdu budu potřebovat i unikátnost.

24.9.2014 20:17 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Naopak interní PK, který nikde jinde nefiguruje, klidně změnit můžeš (kaskádový UPDATE), ale co z toho?
No, mám větší prostor při refactoringu. Nemusí to stát za námahu, to je pravda. Teď mne z fleku napadá takový celkem reálný scénář, že se mi nějké data extrémně namnoží, tak se rozhodnu, že ty staré záznamy přestěhuju do archivu, a ty aktuální přečísluju, protože skrze ten PK na něj odkazují tabulky všude možně.

Možná je to blbost, a nevyplatilo by se to.

A také je pravda, že můžu ze starých PK udělat nový sloupec ID a vytvořit novou řadu PK. Což ale všechno toto můžu zvážit, protože jsem si vědom rozdílu PK a ID.
24.9.2014 21:20 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Můžeš mít děravý ID sloupec s „auto increment“ a někdy to může být fakt hodně a chceš ho setřepat.

Nebo to naopak potřebuješ rozložit na dva stroje, které budou používat auto increment krok po 2 jeden na sudých druhý na lichých aby nedošlo ke kolizi.

Osobně preferuji pk na sloupci s auto-increment v KAŽDÉ tabulce (včetně nějaké unikátně provazovací kde je vysloveně na ho..o) a výslovně JEN pro interní účely DB (případně aplikace), téměř vždy když to tak někde nebylo, to znamenal problém.
Mimo jiné výhody (na cokoliv na přímo odkážeš přes vazbu) to pramení i z toho, že mám takovou jednu knihovnu (PHP), kde se s tím počítá, protože je to obrovské zjednodušení pro generování DB a jejich aplikačních tříd a stavím nad tím i něco jako UID záznamu a přes (vygenerované) meta data dané db jsem schopen přiřadit libovolnému záznamu v libovolné tabulce poznámku, dokument, či uložit jeho historii (v zásadě universálním trigrem do universální tabulky) a to vše universálně i včetně případného ksichtu.

Jeho zásadní neměnitelnost není nutná, ale určitě případná změna musí mít zásadní důvod a často je třeba mít v některých číselnících povinně nějaké položky z daným ID, takže je tam navíc flag (třeba něco jako upravitelný záznam, ale nesmazatelný, neupravitelný a nesmazatelný záznam a u takových se ID fakt nesmí měnit) :).

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
25.9.2014 10:01 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Vždycky s tím byly problémy.... Jaké konkrétně?

Setřepávání autoincrementu či rozklad na dva stroje, to je scénář, kterej se řeší vyloženě výjimečně a když nastane, není problém ho vyřešit např. "zesoukroměním PK" až v době, kdy je to třeba. Práce je to skoro stejná, jako ho založit na začátku, takže vzhledem k raritě takovýchto operací je zakládání speciální externí identifikace klasický případ předčasné optimalizace.

Jinak s tím, že umělé ID se hodí už jen pro standardizovanou práci s tabulkami 100% souhlasím.
25.9.2014 15:22 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Možné scénáře potřeby, jsem napsal ty, které mě napadly, uznávám, že jsou výjimečné a neměl jsem v úmyslu je nějak obhajovat.

Víceméně všechny problémny lze shrnout do krabičky „změna a doplňení struktury či přenesení na jinou DBE“.
Pokud tam tento identifikátor je a interní, tak nerozbiješ nic o čem nevíš( a vždy o něčem nevíš). Při doplnění, nemusíš sahat na stávající strukturu a uděláš doplňkovou tabulku 1-1 přes toto id, matlat to přes dvojitý či trojitý PK je pak zbytečná zátěž a je to nepřehledné a „prosí“ to o komplexnější změnu. Pokud tam to ID je, tak i když je struktura blbě navržená, nebo není zaručena DB integrita, je to (většinou) jednoznačné.

Pokud je ID veřejné nikdy nevíš, který systém se na to navazuje a odkazuje, tedy si myslím, že je lepší vytvořit UID a to zveřejnit.

Pokud je třeba různé systémy propojit, tak je nemožné zajistit complexní integritu, když se vzájemně „identifikuje“ jinak než přes veřejná UID. Takovýto sloupec je naprosto jasný k čemu slouží a nikdo do něj nedrbe, z žádného firmy, či v žádném softu.

I některé zálohovací „operace“ neudrží PK (protože jej vývojáři vnímají jen interně).

"zesoukroměním PK" je pekelný krok, přivedoucí k šílenství ty, kteří ho potřebovali použít a použili, žádný systém není komplexnií a konečný a mělo by být uvažováno už v návrhu, že někdo na něj bude chtít „nezávisle-jedinečně“ navazovat.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
26.9.2014 02:32 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Zesoukromění PK vůbec není pekelný krok - pokud potřebuješ ID přečíslovat, saháš na celou databázi. Oproti tomu operace

ALTER TABLE table 
RENAME id TO private_id,
ADD id INTEGER ;
UPDATE table SET id = private_id ;

je vcelku bezbolestná.

Nechápu, proč bych musel dělat nějakou doplňkovou tabulku a další opičárny. Doplňkovou tabulku musím dělat v okamžiku, kdy by ta vazba nebyla 1:1 a tam to bude blbý tak jako tak.

---

Změna struktury, pokud neměníš význam záznamu v tabulce s sebou nenese nutnost změny ID. Pokud význam toho, co znamená záznam v tabulce, měníš, tak máš problém s UID i ID - stejně musíš zachytit stará UID a co znamenají v nové struktuře db, tak to lze udělat stejně i s ID.

Stejnětak přechod na jinou DBE, pokud je ta rozumná, s sebou nenese nutnost přečíslování ID.

26.9.2014 03:01 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Jak často potřebuješ, aby PK bylo zároveň ID?
Tarmaq avatar 26.9.2014 10:32 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Pokud mam nejaky umely ID, pouziju ho jako PK.
Pokud je PK slozeny (vazebni tabulky), zadne ID nemam.
Takze bych se zeptal spis naopak. Jak casto potrebujes, abys mel krome PK jeste nejake jine ID?
Don't panic!
1.10.2014 23:39 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Můj klasický příklad s blogem.

Články a komentáře. Články mají číselné PK (protože výkon), ale mají textový identifikátor (protože SEO). Komentáře mají složený PK z order + id_post, a identifikátorem je, nepřekvapivě order v rámci článku. V rámci článku počítáno od jedničky. Pak tam můžu mět hlasování, zde žádné ID nepotřebuji. Obrázky, stejně jako články.

Uživatelé: PK plus ID protože SEO.

SOAP,RPC,...: procedura vytáhnout produkt, má přidělené ID (může být klidně PK, nebo jen náhodně generovaný token, záleží zda mám nebo nemám session, a jak jsem si to vymyslel 1), upravím hodnoty, pošlu zpět (pod ID), ID zapomenu.

Takže sečteno podrženo: 1. buď používám extra ID z jiných důvodů, 2. nebo mě konkrétní hodnota ID nezajímá, 3. a v ostatních případech si pro mě za mě to PK jako ID použijte.


1 Je zajímavé, že pak vznikají takové zábavné situace, kdy je v dokumentaci k webové službě řečeno, že pro každou akci se musí zavolat metoda createToken(), a na závěr releaseProcesing(), a když to ignoruju, tak to shodou okolností funguje taky. Proč asi? A co za magické chyby mě čeká v budoucnu?
xkucf03 avatar 1.10.2014 23:56 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Komentáře mají složený PK z order + id_post, a identifikátorem je, nepřekvapivě order v rámci článku. V rámci článku počítáno od jedničky.

Jak řešíš unikátnost/generování toho ID komentáře v rámci článku? Pomocí sekvence v DB asi ne, to bys potřeboval sekvenci pro každý článek.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 00:07 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
INSERT INTO "comment" (id_post, "order", title) VALUES ( 42, (SELECT COALESCE(MAX("order"), 0) + 1 FROM "comment"), 'Lorem ipsum.' );
xkucf03 avatar 2.10.2014 00:46 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Jednak by v tom vnořeném dotazu měla být podmínka na článek. Ale hlavně: bude celá ta tabulka zamčená pro případ, že by jiná transakce paralelně počítala maximum a následně vkládala záznam?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 01:10 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Jednak by v tom vnořeném dotazu měla být podmínka na článek
Samozřejmě, přehlédl jsem se.
Ale hlavně: bude celá ta tabulka zamčená...
Zde je možnost volby. Ale při optimistické transakci (pesimistickém scénáři) tabulka zamčená nebude, a tudíž to bude vypadat tak, že obě transakce získají shodné MAX, a tak ta druhá chcípne na PK. Což si aplikace vyzvedne, a pokusí se uložit znova (nebo se zachová jinak, záleží na případu).
2.10.2014 18:13 logik
Rozbalit Rozbalit vše Re: Sql primary key
No a jaký je důvod volit řešení, kde buď bude zamčená celá tabulka, nebo budou chcípat transakce a bude se to muset ošetřovat, když lze zvolit řešení, které tyto neduhy nemá?

2.10.2014 18:45 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Žádný.

Ale takový scénář není příliš častý. Vždycky ošetřuji úspěšnost dotazu. A když mi tam něco chcípne, což se může stát častěji, než jak se tu snažíš naznačit. Tudíž ověřit jeden scénář navíc, ve skutečnosti udělám samozřejmě.
2.10.2014 20:28 Logik
Rozbalit Rozbalit vše Re: Sql primary key
1) V velké většině aplikací patřičné podmínky ověřuje už aplikační logika a tedy selhání dotazu do databáze je nějaká vážnější chyba, na kterou není reakce vše jen tak zopakovat. Málokterá aplikace vůbec na zopakování dotazu připravená je.

2) Nutnost přehrání transakce při chybě je jen jeden z projevů tohoto chybného návrhu. Další - a neodstranitelný - problém je, že zápisy do jednoho threadu na sobě nejsou nezávislé, což s sebou nese to, že na sebe navzájem čekají a výkon databáze jde do kopru.

Databáze a sekvence jsou vymyšleny právě tak, aby tento problém řešili, fakt nechápu, proč místo použití nástrojů, které jsou k vytváření unikátního identifikátoru určeny (tedy sekvence), vymýšlíš vlastní polofunkční postupy. Přijde mi to, jako bys zatloukal hřebíky šroubovákem.
Tarmaq avatar 2.10.2014 13:43 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Moc nerozumim tomu, jak muzes sloupci order rikat identifikator, ale budiz.
Ja bych tuhle situaci resil uplne jinak. Mel bych tabulku s clankama, tabulku s komentarema a vazebni tabulku mezi komentarem a clankem. V tabulce s komentarema bych nemel zadny order sloupec, staci prece seradit podle data vlozeni zaznamu.
Don't panic!
xkucf03 avatar 2.10.2014 13:47 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Vazba mezi komentářem a článkem je M:N? Stejný komentář může být pod více články? Proč vazební tabulka?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Tarmaq avatar 2.10.2014 14:45 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Vazba mezi komentářem a článkem je M:N? Stejný komentář může být pod více články?
Ne, unikatnost prirazeni komentare k clanku resi unikatni index.
Proč vazební tabulka?
Jasne, u tohohle prikladu je mozna vazebni tabulka kanon na vrabce, kazdopadne tohle reseni mi prijde fajn proto, ze muzu mit vice druhu komentaru - napr. pokud bych to bral po vzoru abclinuxu.cz, muzu mit komentar k clanku, komentar ke zpravicce, komentar ke screenshotu desktopu.. atp.
Don't panic!
2.10.2014 13:52 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Identifikátor je (order, id_post). order sám o sobě nese jen informaci o pořadí položky.

Tvé řešení je zcela špatně, protože komentáře nejsou k článku ve vazbě M:N, ale N:1. Nebo ty snad komentuješ více článků jedním komentářem?

To, že ty budeš řadit podle data vložení záznamu se nic neměnilo. Akorád uděláš PK podle (id_post, created).
xkucf03 avatar 2.10.2014 14:08 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Tam ale nemáš zaručenou unikátnost1 – leda že bys to při selhání zkoušel znova a znova, dokud se netrefíš do okamžiku, kdy zrovna nikdo jiný komentář nevkládá. Ale to považuji za ošklivé řešení.

[1] byť je to málo pravděpodobné, že by dva komentáře vznikly ve stejný okamžik

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 14:27 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Unikátnost mám zajištěnou PK nad (order, id_post).

Pravděpodobnost se opakovaným pokusem o uložením drasticky snižuje. Odhadem u třetího pokusu bude neměřitelná.

Na druhou stranu, automaticky nový pokus o uložení je jen jedna z možností. A netvrdím, že nejvhodnější.
xkucf03 avatar 2.10.2014 14:33 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Co se týče pravděpodobností, celkem souhlasím, ale stejně to považuji za špatné řešení. Zbytečně to zesložiťuje aplikační logiku a přínosy nějak nevidím.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 17:04 logik
Rozbalit Rozbalit vše Re: Sql primary key
Přesně - otázka neleží jestli to jde tak dělat - ale proč to tak dělat...
2.10.2014 17:15 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Zkus navrhnout jak si představuješ správné řešení. Já se domnívám, že vzhledem k okolnostem to nemohu navrhnout jinak (pomiňme mé chyby).
2.10.2014 17:33 logik
Rozbalit Rozbalit vše Re: Sql primary key
Co je špatného na umělém primárním klíči se seqvencí - která je přesně navržena k tomu, aby se nemuseli dokolečka opakovat transakce - a řazení dle CREATE_DATE, ID

že to tak nemůžeš navrhnout (teda kromě Tvého vrozeného odporu k umělým klíčům :-))?
xkucf03 avatar 2.10.2014 17:48 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Např. na svém blogu to mám takhle: komentář má číselné ID (PK) a pak atribut, k jakému článku patří a jestli je to odpověď na jiný komentář1. Nevadí mi, že ID komentářů pod jedním článkem netvoří souvislou řadu. A aplikace je jednodušší, protože nemusí řešit ptákoviny typu, co dělat, když dojde ke konfliktu PK (pořadí nebo čas) – protože k němu nedojde, ID přidělí automaticky databáze (sekvence). A i kdyby tu k chybě došlo (např. někdo tu sekvenci vynuloval), tak aplikace chybu akorát ohlásí ale nebude ji řešit.

[1] což je sice redundantní informace a denormalizace – když víme, na co je to odpověď, nepotřebujeme evidovat článek, protože k němu můžeme rekurzivně skrz ten strom dojít – ale je vhodné mít možnost vytáhnout si všechny komentáře pod daným článkem (a strom si poskládat až z nich)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 18:18 logik
Rozbalit Rozbalit vše Re: Sql primary key
ad poznámka [1]

Normální formy hovoří o závislosti sloupců (nikoli konkrétních polí v jednom řádku) - takže to normální formu neporuší. To by musela existovat funkční závislost

CLANEK = f(ODPOVED)

a ta neexistuje, protože tu f nelze definovat na NULL hodnotě. Takže máš návrh z hlediska normálních forem (i z hlediska normálních postupů :-)) v pořádku.
2.10.2014 18:42 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Myslím, že jsem doma.
8.10.2014 01:26 fean
Rozbalit Rozbalit vše Re: Sql primary key
Já taky. Ten člověk vůbec neví, o čem mluví.
9.10.2014 12:04 logik
Rozbalit Rozbalit vše Re: Sql primary key
Co z toho co jsem psal je špatně?
2.10.2014 18:52 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Takže máš něco jako https://blog.frantovo.cz/c/313/Java%208%3A%20lambdy%2C%20uz%C3%A1v%C4%9Bry%20a%C2%A0platnost%20prom%C4%9Bnn%C3%BDch

kde 313 je předpokládám PK.

Ale obvykle jsou blogy dělány takto: http://lambda.jstolarek.com/2014/09/promoting-functions-to-type-families-in-haskell/, případně takto: http://phpfashion.com/psat-isomorfni-webove-aplikace

Tvůj způsob je regulerní, a jistě to v mnoha případech stačí. Pokud ti to nevadí, tak ti to nevadí. Ale těžko mi můžeš argumentovat, že to, že ti to nevadí znamená, že je to obecně lepší? Nebo, že ošetřovat neúspěch uložení záznamu je ptákovina. Protože ten neúspěch ti může nastat tím, že ti dá někdo komentář ke smazanému článku. A pokud ti nevadí chyba v této situaci, tak nemusíš řešit chybu ani při mé ptákovině. Ve skutečnosti nemusíš řešit spousta věcí.

Možná bych měl lépe definovat požadavek:
  • článek má (bo seo) definovaný textový slug
  • komentáře jdou za sebou (tedy nikoliv strom)
  • jejich čísla zveřejňujem, protože chcem, aby uživatelé na sebe mohli odkazovat
xkucf03 avatar 2.10.2014 19:22 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Tvůj způsob je regulerní, a jistě to v mnoha případech stačí. Pokud ti to nevadí, tak ti to nevadí.

Nevadí, je to tak záměrně :-) Jen trochu objasním tu motivaci:

Nemám rád cizí zkracovače – ale na druhou stranu, krátké URL se někdy hodí – proto je tam ID hned na začátku – stačí napsat https://blog.frantovo.cz/c/313/ a dostaneš se na tentýž článek. Ten zbytek je tam jen pro to, aby uživatel přicházející odjinud věděl, na co kliká – po najetí myší na odkaz nevidí jen nicneříkající ID, ale nadpis článku, včetně češtiny a mezer.

V databázi žádné „slugy“ uložené nejsou – do URL se dává aktuální název článku.

Název článku se může měnit, což je mj. důvodem k tomu, že po zobrazení článku https://blog.frantovo.cz/c/313/ se ti přepíše adresa na ten plný tvar. A zároveň je tento plný tvar uveden uvnitř XHTML jako kanonické URL (pro vyhledávače, aby věděli, co je správná adresa a že je to jedna stránka, ne víc stránek se stejným obsahem).

Nebo, že ošetřovat neúspěch uložení záznamu je ptákovina. Protože ten neúspěch ti může nastat tím, že ti dá někdo komentář ke smazanému článku. A pokud ti nevadí chyba v této situaci, tak nemusíš řešit chybu ani při mé ptákovině. Ve skutečnosti nemusíš řešit spousta věcí.

Ošetřování chyb je zase jiná věc. Přiznám se, že ten systém je pořád ve vývoji a hodně věcí tam ošetřených není – v tom smyslu, že se prostě vyhodí výjimka a ta vyletí nahoru a nakonec vyústí v HTTP 500 chybu. Některé věci chci ošetřit lépe – převést na jiné výjimky a potažmo uživatelsky přívětivé chybové hlášky. Je to víceméně věc konfigurace, jaké hlášky se pro jaké výjimky budou zobrazovat.

Jenže kdyby docházelo ke konfliktům (pořadí/data), je to o dost složitější – musím tam přidat nějaký IF, kde zjistím, že jde právě o chybu PK a ne jinou SQL výjimku a pak nějaký cyklus, který to bude zkoušet znova a znova… možná s nějakým limitem, což je další IF + počítadlo. Prostě to zvyšuje složitost programu a to bez nějakého přínosu.

Obecně proti přirozeným nebo složeným klíčům nic nemám, nezavrhuji je a někde jsem je tu i bránil před lidmi, kteří mají tendenci všude bezmyšlenkovitě nacpat umělé číselné ID. Ale tady mi prostě přijde, že to číselné ID je lepší řešení.

článek má (bo seo) definovaný textový slug

V mém případě nemá, v DB ukládám jen nadpis článku a URL je z něj odvozené v aplikaci.

komentáře jdou za sebou (tedy nikoliv strom)

Chronologický pohled lze doplnit, je jednodušší, ale stromové diskuse mám radši.

jejich čísla zveřejňujem

proti zveřejňování ID/PK nic nemám

protože chcem, aby uživatelé na sebe mohli odkazovat

Takže je to přeci jen strom. Nebo možná i orientovaný acyklický graf (pokud uživatel může odkazovat z jednoho komentáře více jiných). Nebo možná i cyklický, když povolíme dodatečnou editaci příspěvků :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 20:00 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Řešíme validitu zadání, nebo technickou implementaci? - já jen, že nemůžeš prostě zamítnout slug, že máš raději strom, atd.

Ošetřování chyb je zase jiná věc...
Jak jsem psal na jiném místě, insert ti může spadnout z mnoha důvodů. FK, PK, Check, Vypnutá databáze. To nejjednoduší, co se dá udělat je, zabalit to celé do obecné hlášky "zkuste to prosím znova". Nehledě na to, že, pokud dodržíš mé zadání (které věřím není nijak neobvyklé), tak se toho souběhu stejně nevyhneš.

Takže mě by zajímalo: Když máš v zadání slug, proč zveřejňovat PK? Máš-li v zadání komentáře sloupce order, proč komentáři vytvářet ještě jeden sloupec s ID, když mi k ničemu není?
xkucf03 avatar 2.10.2014 21:02 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key

Mít tam oba sloupce je blbost, když už si dáš práci s dopočítáváním pořadí v rámci článku, tak tam to ID (jedinečné přes všechny komentáře) mít nemusíš (máš složený PK). Ale otázka je, jestli si s tím tu práci dávat, jestli to za to stojí. IMHO ne, protože těch problémů a nevýhod je víc.

Pokud jde o ta krátká čísla, aby se komentář mohl odkazovat třeba na [5] místo na [21576] tak to by šlo řešit přepočtem v aplikaci, v prezentační vrstvě – při výpisu komentářů je budeš číslovat od jedničky, řazené budou podle ID a komentáře se nebudou mazat (maximálně označovat jako smazané), takže pořadí bude stabilní.

Ale i tak mi to přijde jako chybný návrh – technika by měla lidem usnadňovat práci a ne je nutit opisovat nějaká čísla jako v době psacích strojů. Takže bych to udělal tak, že uživatelé budou klikat na tlačítka a budou se z toho generovat nějaké pěkné odkazy – a pak bude úplně jedno, že kdesi uvnitř se odkazuješ na [21576] místo na [5].

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
8.10.2014 01:38 fean
Rozbalit Rozbalit vše Re: Sql primary key
Myslím si, že senior by mě s něčím takovým poslal do někam.
Tarmaq avatar 2.10.2014 14:53 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Identifikátor je (order, id_post). order sám o sobě nese jen informaci o pořadí položky.
V tom pripade se ti tento identifikator vubec nelisi od PK, takze moc nechapu proc jsi ten priklad uvedl jako odpoved na muj dotaz
Don't panic!
2.10.2014 17:07 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Souhlasím, trochu to v tom příkladu zapadlo. Pointa byla v:

Takže sečteno podrženo: 1. buď používám extra ID z jiných důvodů, 2. nebo mě konkrétní hodnota ID nezajímá, 3. a v ostatních případech si pro mě za mě to PK jako ID použijte.

(order, id_post) je implementace v databázi. Na venek mám vložení nového komentáře identifikované jen IDem článku (což není PK), a úprava komentáře (je-li), tak pomocí ID článku (není PK) a order (není PK, zato je ID (neměnný a unikátní identifikátor v rámci článku)).

Řešení, které definuje každému co jeho jest. ID je opravdu jen v případě kdy se jedná o ID, a PK je jen tam, kde je to opravdu PK.

Když nad tím trochu popřemýšlíte, tak si všimnete, že většina ID nemůže být PK, protože to vyžadují jiné okolnosti, nebo souvislosti. A možnost to celé otočit a třeba SEO slug nějak generovat na základě PK přináší další a další komplikace.
2.10.2014 17:40 logik
Rozbalit Rozbalit vše Re: Sql primary key
Směšuješ tzn. významové identifikátory (např. seo-slug) s nevýznamovým (klasické ID).

Každý se používá k jinému účelu a jsou na něj i jiné požadavky. Např. seo-slug je záhodno měnit, naopak umělé id (např. z důvodů archivace, komunikace s okolními systémy atd...) by se měnit nemělo.

--

V příkladu pak tyto dva různé identifikátory zaměňuješ, což vede k problémům. Např. když potřebuješ nějaký komentář smazat.... Přečísluješ order? pak editace následujících komentářů povede k zmaštění celé databáze. Nepřečísluješ order? Pak jsi právě úspěšně zavedl umělý identifikátor, kterému nesprávně říkáš pořadí.
xkucf03 avatar 2.10.2014 17:50 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Např. seo-slug je záhodno měnit
Aby odkazy přestaly fungovat? Tak to je SEO za všechny prachy.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
2.10.2014 18:23 logik
Rozbalit Rozbalit vše Re: Sql primary key
Před publikací článku "na veřejnost" je samozřejmě záhodno, aby seo slug se měnil podle provedených úprav článku a autor ho viděl a případně i mohl modifikovat, je-li třeba.
2.10.2014 18:44 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Problém bude v něčem jiném. Zkus se v tom najít:

order: je pořadí, určuje pořadí komentáře (takové to [5]), zároveň to je to identifikátor v rámci článku. Žádné přečíslování nedělám, protože samozřejmě když jeden komentátor bude odkazovat na jiný, důsledky si domysli. Takže splňuje požadavky na ID.

seo-slug: je identifikátor. Naopak jsem se tu pokoušel demonstrovat, rozdíl mezi PK, který je závazný v rámci databáze, a ID, který je závazný v jiném kontextu. Například na seo-slug je obvykle kladen požadavek, že by se neměl nikdy měnit. Tudíž splňuje požadavky na ID. Že má ještě další atributy nevytváří rozpor.

Je mi líto, obávám se, že to mám správně.
2.10.2014 20:27 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Ad order - pokud smazané komentáře nemažeš, pak order není nic jiného než sekvence s doménou pro jeden článek. Jaký je důvod omezovat doménu této sekvence na jeden článek a tím se připravit o nativní nástroje databáze pro vytváření sekvencí, a místo toho používat "handmade" sekvence se všemi dopady na výkon a složitost aplikace? Jaký konkrétní benefit přináší to, že identifikace (nikoli pořadí, je to "děravé", čili prvek s číslem n nemusí být n-tý) je lokální vzhledem k článku?

Nese to s sebou jen nevýhody: při odkazech na komentáře musím používat složené klíče, což se píše špatně, ORM a další nástroje mají pro to zpravidla omezenou podporu, má to negativní dopad na výkon, musí se psát podpora pro zhavarované transakce při vytváření komentářů atd. Navíc - tím, že je PK významový, tak se zesložiťují další operace s komentáři jako třeba přesun pod jiný článek.

Ad seo - seo_slug: ten samozřejmě potřeba měnit je: před publikací článku/stránky ta zpravidla prochází schvalováním a změnami a slug by měl reflektovat tuto změnu. A právě proto, že je to SEO slug, tak se mj. ladí i podoba samotného slugu, aby se dobře chytili vyhledávače. Tudíž seo-slug požadavky na ID nesplňuje - právě proto, že je to VÝZNAMOVÝ identifikátor.
8.10.2014 01:31 fean
Rozbalit Rozbalit vše Re: Sql primary key
No to je teda argumentace. Hele, četl jsi, co vlastně píše? Teda, ne, že bych s tacoberu ve všem souhlasil, to sice ne. Ale přijde mi, že se ho snad schválně nepokoušíš pochopit. Hádáš se o věcech, který ani neřekl.
8.10.2014 12:28 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Jsi Tacoberu II, nebo troll otravný?

Prolít si tady diskusi a vyplodil asi šest příspěvků jak někdo něco nepochopil a je totálně blbej, ale argument žádnej.
8.10.2014 16:21 fean
Rozbalit Rozbalit vše Re: Sql primary key
Budem kamarádi? Taky se neunavuješ argumentama, co by měli smysl.
8.10.2014 16:26 Kolemjdoucí
Rozbalit Rozbalit vše Re: Sql primary key
Jděte se hádat jinam!
8.10.2014 17:37 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
A ze všeho nejhorší jsou trpaslíci…
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
8.10.2014 16:43 Kolemjdoucí
Rozbalit Rozbalit vše Re: Sql primary key
Ad order - já bych řekl, že z příkladu je to jasný. Prostě píše o modelování aplikace. Ty se tu bavíš o praxi, a nejsi schopen opustit myšlenku. Dopady na výkon a složitost aplikace bych prosil doložit nějakými čísly.

PK není významový, co to meleš?

Ad seo - seo_slug - jakože se ti identifikátor u https://www.youtube.com/watch?v=R5-8JpdRQdk běžně v čase mění, a za týden je to https://www.youtube.com/watch?v=lURK5RLvZ2c a za měsíc https://www.youtube.com/watch?v=U9JNiqv-2hM ? Ty voe!

A to filozofování o Významovém identifikátoru sem nějak nepobral.
9.10.2014 12:01 logik
Rozbalit Rozbalit vše Re: Sql primary key
- ano, dokládá obecné tvrzení konkrétní implementací. Což je typický nekorektní argument - proč bych dokládal čísly? To, že zamykání záznamů a vzájemné čekání transakcí na sebe má značný dopad na výkon vi i tříměsíční krtek. - ano, z příkladu je jasné, že tacoberu udělal sloupec ORDER, který ale funguje úplně stejně jako klasický autoincrement sloupec. Nemá žádné výhody plynoucí z toho, že je to id lokální v rámci článku, pouze nevýhody spojené s tím, že nemůže využít autoincrement poskytovaný databází - u publikovaných stránek se seo slug zpravidla nemění - i když výjimkou to také není (např. při částečné změně obsahu stránky). Před publikací stránek na veřejnost se naopak ladí a tedy mění velmi často. Což jsem psal a kdybyste místo svého posmívání četl pořádně, co ostatní píšou, tak už byste to věděl. A opět dokládáte obecný princip jedním konkrétním případem - tedy opět nekorektní argumentace.

- to že si něco nepobral není moje chyba :-)
9.10.2014 14:48 Kolemjdoucí
Rozbalit Rozbalit vše Re: Sql primary key
- Aha. Takže obecná definice, neprojde. Konkrétní příklad, na kterým to demonstrovat, to je zase nekorektní argument. Jak by sis vlastně představoval ty korektní argumenty? Třeba jako, že primár by jako identifikátor pro externí služby nepoužil ani tříměsíční krtek? No, hezký.

- Z příkladu je jasné, že sloupec ORDER je tam protože to bylo v zadání. Bylo v zadání, že musí určovat pořadí komentářů v článku. Ostatně proto ho asi tak pojmenoval, řek bych. Takže mi laskavě ukaž, jak by se na takovém sloupci dal použít autoicrement.

- Asi je každému jasné, kdo tady čte pozorně.

Tak, slunce v duši.
9.10.2014 16:35 logik
Rozbalit Rozbalit vše Re: Sql primary key
- "Obecná definice" ale jaksi neprošla proto, že měla více nevýhod než výhod, nikoli proto, že byla obecná. Konkrétní příklad pak nijak na předložené argumenty nereagoval, jen na něm byly krásně ukázatelné konkrétní nevýhody jeho přístupu.

- Sloupec ORDER byl v zadání? On někdo v zadání předepisuje strukturu databáze? Od takového člověka bych si zadání dělat nenechal. Pole ORDER nebylo v zadání, pole ORDER je tacoberyho výmysl kterým ukazoval, jak se "obchází bez umělého id". No tak jsem prostě ukázal, že:

A) to není pořadí, protože pořadí nemá díry, zatímco jeho implementace ano. Takže je to normální umělý identifikátor, pouze s menší doménou platnosti

=> pokud bych přistoupil na tvoji interpretaci, že mít v databázi pořadí komentáře v článku bylo v zadání, tak zadání nesplnil.

B) se to pole svým chováním (a tedy tím, co umožňuje za operace) nijak neliší od "umělého id", akorát má daleko více práce s jeho generováním a zbytečně zatěžuje databázi tím, že se mu tlučou transakce
8.10.2014 01:29 fean
Rozbalit Rozbalit vše Re: Sql primary key
No, jak já to tu pročítám, myslím si, že v tom máš bordel spíše ty.
8.10.2014 01:35 fean
Rozbalit Rozbalit vše Re: Sql primary key
No jako chápu. A dává to logiku. Dejmetomu. Ale proč to teda většina těch blogů tak nepoužívá? Mají ty komentáře očíslovaný jak píšeš, ale pod odkazem je to schovanej ID... teda Primární Klíč jak tomu říkáš ty.
8.10.2014 16:18 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Jak jsem psal jinde. Mé teze jsou čistě akademické. V praxy se často rezignuje na akademickou čistotu. Protože výkon, pohodlnost, práce navíc. Chtěl jsem jen zdůraznit, že je dobré ten rozdíl znát.
9.10.2014 12:03 logik
Rozbalit Rozbalit vše Re: Sql primary key
Jenže ty "akademické teze" mají sloužit k takovému návrhu databází, aby se s nimi co nejlépe v praxi dělalo.

Pokud máte nějakou akademickou tezi, která se v praxi nepoužívá, protože nepřináší tolik užitku, kolik stojí práce, tak je to špatná teze, ať už ji nazvete akademickou či nikoli.
9.10.2014 14:39 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Je rozdíl mezi tím, a/ ignoruju akademické teze, protože jsem nezkušený, b/ ignoruju akademické teze, protože výkon, ekonomie, něco jiného.

Myslím, že už je to poněkolikáté , kdy se ti pokouším vysvětlit tu samou věc, a ty ji pokaždé ignoruješ. S dovolením, už se nebudu namahat reagovat.
9.10.2014 16:56 logik
Rozbalit Rozbalit vše Re: Sql primary key
Neignoruju, já ty tvoje "akademické teze" rozporuju.

Protože ty sis vybásnil nějaké teze, a když Ti lidé proti nim vznesou argument, že jsou blbě, tak prohlásíš, že jsou akademické a tedy je verifikovat účelností není správné. Ale to je prostě blbost. Akademické teze vznikají proto, že je snaha zachytit "best practicies" - tj. věci, pravidla, která jsou obvykle špatně nedodržet. Tedy normální forma je klasická "akademická teze", protože v 95% případů je denormalizovaná databáze nešikovně napsaná databáze. Že pak jsou výjimky kdy je z výkonnostních důvodů denormalizace potřeba "protože výkon", na platnosti té teze nic nemění.

Ty však postuluješ teze, které jsou naopak: které budou nepraktické v 95% případů, a v 5% případů mi možná k něčemu budou. A takové teze, ať už je nazveš akademické nebo ne, jsou prostě blbina.

A vrchol té "akademičnosti" je, když akademickou tezi: "ID nemusí být neměnné" nedokládáš ničím jiným než tím, že dnes používané implementace databází tu neměnnost nevyžadují - čili čistě praktickou stránkou věci. Přitom právě akademické teze o dobrém návrhu databáze (např. normální formy) nikdy žádná databáze nevyžadovala - a přesto jsou považovány za platné.

Takže - ty prostě nedostatek argumentů zakrýváš tím, že si svoje teze, které podle mne nejsou dobré, prohlásil "za axiomy", které se nedokazují ale které jsou z nějaké vyšší moci platné. Nu a s tím prostě nesouhlasím a snažím se Ti ukázat, že ty teze jsou blbina. A protože jsi pro ty teze nepředložil žádné validní argumenty, proč by měli platit, tak jsem Ti je vyvracel tak, že jsem Ti ukazoval, proč by platit neměly: že např. narozdíl od normálních forem, které vedou na praktický návrh tabulek, tak Tvoje pravidla jen přidělávají práci a zhoršují výkon DB, aniž by vlastně přinesly nějaký benefit, jak jsme ukázali na Tebou samotným zvoleném příkladu s blogem.
2.10.2014 18:21 logik
Rozbalit Rozbalit vše Re: Sql primary key
Řadit podle data vložení záznamu nelze, protože to je pouze kvaziuspořádání a nikoli uspořádání: tj. nedefinuje to jasně pořadí záznamů.
1.10.2014 23:22 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Ne, tak otázka nestojí. Otázka stojí:

jak často potřebuješ, aby PK zároveň nebyl ID. Protože pouze rozumně častá potřeba znamená, že má smysl si dávat práci s tím vytvářet další políčko, když jako ID mohu využít PK, který tam mám tak jako tak.
1.10.2014 23:43 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Otázka stála takto. Buď se mě snažíš přesvědčit o věci, ve které nejsem ve sporu, a nebo fakt nevím.

A na tvou otázku bych odpověděl takto.
2.10.2014 09:41 Logik
Rozbalit Rozbalit vše Re: Sql primary key
1) Už dávno se tu nebavíme o otázce položené v článku, ale o otázce z té otázky v článku vyplývající, a to konkrétně dvě 1a) jestli je dobré mít v tabulce umělé ID (to je defakto ta z článku) 1b) jestli je dobré to umělé ID užít jako veřejné ID

Konkrétně v tomto vláknu jsme se s Šangalou (viz http://www.abclinuxu.cz/poradna/databaze/show/395521#173) shodli, že už z důvodů uniformní práce s tabulkami pomocí různých nástrojů nebo ORM frameworků se hodí mít uniformní strukturu tabulky a řešili jsme 1b. Takže jestli ses zas vrátil k 1a, tak mícháš témata.

2) To ovšem není odpověď na otázku. To je ukázka jednoho konkrétního řešení bez umělého ID, která ale nijak neodpovídá na otázku, co je výhodnější. Nebo teda spíše odpovídá, protože je vidět, že najednou musíš v hlavě řešit, co bude ID v jednotlivejch akcích (místo co bys automaticky použil ID), může ti zdechnout transakce na kolize, které bys pomocí ID vyloučil atd... Takže je to spíš dobrý příklad proč zavést umělé ID :-)

2.10.2014 14:26 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
1/ V tom případě odpověd na otázku autora, na tvou 1b zde, a zde, plus konkrétní příklad.

2/ Je to odpověď na otázku. Dostačující pro inspiraci. O nic více jsem neusiloval.

Co se týče tvých závěrů, nejsem schopen se s nimi ztotožnit.
2.10.2014 14:54 logik
Rozbalit Rozbalit vše Re: Sql primary key
1) Tímto jsi dovedl dovednost opakovat své názory aniž bys reagoval na argumenty protistrany do dokonalosti. Pouze jsi ocitoval svůj názor, bez jakékoli argumentace proč to děláš zrovna tak. Za normální považuji když člověk své názory podkládá argumentem (přičemž argument, že něco nemá být neměnné, protože to databáze nepožaduje je asi tak validní, jako tvrdit, že není chyba mít všechny proměnné s jednopísmenným názvem, protože významové názvy programovací jazyk nepožaduje). Je to defakto dogmatismus.

2) V podstatě totéž: uvedení konkrétního řešení nějaké problematiky podle Tvého paradigmatu žádným způsobem neodpovídá na otázku, proč je Tvé paradigma lepší než alternativní paradigmata, takže to opět ve skutečnosti není odpověď na položenou otázku, protože v té je samozřejmě nevyřčená spoluotázka A PROČ?

To, že to tak dělat lze je samozřejmě pravda. To, co jsi doteď nevyvrátil je tvrzení, že Tvůj přístup nepřináší tolik výhod, kolik přidělá při vývoji aplikace práce. Konkrétní důvody jsem psal já i jiní, opakovat je dokolečka asi nemá smysl.
2.10.2014 17:23 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Jsou různé způsoby jak přistupovat k názorům a myšlenkám druhých. Špatné čtení patří mezi ně.
2.10.2014 17:44 logik
Rozbalit Rozbalit vše Re: Sql primary key
Až začneš používat argumenty, budu na ně reagovat.
8.10.2014 01:39 fean
Rozbalit Rozbalit vše Re: Sql primary key
Ty seš mi ale vtipálek. Tomu, co tady píšeš říkáš argumenty? Mi je ukaž.
26.9.2014 11:07 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Zesoukromění jsem špatně pochopil, ale že bych z tvého řešení a z následných úprav byl nadšený, tak to bych rozhodně nebyl, má to dopad na všechny SQL dotazy - mě by to bolelo.
„Doplňková“ tabulka je naprosto běžný neinvazivní způsob rozšíření systému.

Dělej si to jak chceš ;), já se držím toho co jsem napsal, pokud je ID = PK != veřejné UID, tak vždy je a bude velké napětí při update/upgrade jednoho z celků (bo daný systém to třeba sesype nebo kdoví co), pokud ID = PK = veřejné UID, tak to může být omezující a procesně těžce prakticky zaručitelné při vývoji.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
1.10.2014 23:27 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Jo, možná jsem přehodil co bude veřejný a soukromý klíč, psal jsem to rychle.

Pořád dokolečka opakuješ bude je velké napětí.... atd... Ale žádný konkrétní reálný scénář (kolikrát v životě jsi sesypával idčka?) kde to byl problém jsi zatím nepřinesl.

To sesypávání idček je např. scénář v podstatě nereálný, protože na tabulku, kde je tolik záznamů, že se musí sesypávat, se zpravidla není proč odkazovat (např. tolik lidí na světě není apod.).

Samozřejmě, možná databáze NSA a dvě další aplikace vymyslíš, ale zas jedna věc je "good habit" a druhá věc vývoj specializovanejch datamining aplikací. Tam zas stejně už řešíš úplně jiný problémy....
2.10.2014 00:45 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Dokolečka :-) už se mi to stalo, po upgrade jednoho systému neodpovídala PK_ID, na které se adresoval druhý systém a nedošlo se na to hned, tak si asi představ jaké důsledky to mělo - proč to se nedozvíš, protože dodavatel systému byl a je jak každý jiný, ručí si za svoje a tvoje provázání ho ani za mák nezajímá, pokud DB má veřejný identifikátor (na základní tabulky), tak má definované veřejné rozhraní a neporuší ho nikdo ani při sebešílenější změně struktury, bo je to do očí bijící a nic-neovlivňující.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
2.10.2014 09:15 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Pokud máš systém, který Ti svévolně mění PK, tak je samozřejmě užít jako veřené ID nemůžeš. Ale takovou věc normální databáze nedělá.

Pokud nejde o databázi, ale o nějakej komplexnější systém od nějakýho dodavatele, tak asi holt nedeklaroval neměnnost ID - a pak byla chyba toho, kdo ty systémy na základě toho spojoval. Když nad něčím nemám kontrolu, tak se mohu spolehnout pouze na deklarované invarianty.

A pokud ji deklaroval ale porušil, tak co by mu bránilo porušit jiná data....

To jsou ale všechno jiné případy, než když navrhuji systém a tedy za neměnnost ID ručím, takže to IMHO není relevantní protipříklad.
2.10.2014 13:58 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Pokud máš systém, který Ti svévolně mění PK, tak je samozřejmě užít jako veřené ID nemůžeš. Ale takovou věc normální databáze nedělá.
Dělá.
2.10.2014 14:44 logik
Rozbalit Rozbalit vše Re: Sql primary key
Která normální databáze ti svévolně mění data???
19.9.2014 09:03 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

To je rozhodně správně, pokud to někdo přebírá jako primární klíč či jednoznačný identifikátor, tak je to na zabití.

Jak pak řešit když (ještě) není znám, nebo když se potkají dva naprosto rozdílné z různých zdrojů, nebo dojde-li k přečíslování, když je třeba držet i historii, kterou zdroj neřeší.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
19.9.2014 12:00 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Tak.

Prosakuje implementace. Brání mi to svobodně refaktorovat databázi.

Což mě tedy u @Kita s jeho katgorickou představou o zapouzdření poněkud překvapuje :-)
19.9.2014 19:48 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Existuje snad nějaká nedemagogická vazba mezi syntetickými klíči v tabulce a veřejnými přístupovými metodami k atributům objektu?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
13.9.2014 22:53 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Dodatečně jsem si uvědomil, že rodné číslo, EAN ani telefonní číslo de facto nejsou čísla, ale posloupnost číslic - tedy stringy. Nesplňují požadavek některých diskutujících, aby PK byl číslo.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
14.9.2014 13:37 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Rodné číslo jako primární klíč by mě rozpůlil - já má dvě rodná čísla, jedno asi do 17 a od 17 pak druhé, a to první do valné většiny systémů nelze zadat :-).
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
19.9.2014 12:01 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Off-topic: To jako fakt? Čím to?
19.9.2014 14:00 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Jasně, že je to fakt, takových lidí bylo více, jednoduše proto, že byly doby, kdy u nás nebyly počítače a zajištění integrity a dělitelnosti 11 bylo o matematických schopnostech daného člověka, pominu-li, že z toho pravidla existovala výjimka, která lehce někoho zmátla.
No a pak nastoupila doba, kdy počítače byly a těm se to nelíbilo, tak se měnila rodná čísla na všech dokumentech včetně rodného listu.

Ještě více než 5 let po změně, jsem měl problém u voleb a věřím, že se někdy někde něco ukáže, když to budu nejméně potřebovat.

Jedná se sice o absolutní změnu, jednoznačného identifikátoru, ale pokud by k tomu došlo nyní, tak bych systémově tuto informaci chtěl mít podchycenou, protože prostě spousta dokumentů RČ obsahovala a byli a jsou i někde v papírové podobě.
Jistá pojišťovna se z toho vzpamatovávala dlouho - už u ní nejsem, ale myslím že to doposud nepobrali.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
19.9.2014 18:15 Filip Jirsák
Rozbalit Rozbalit vše Re: Sql primary key
Výjimka na dělitelnost 11 neexistovala, ale prý se stávalo, že když někdo vypočetl, že kontrolní číslice by jednoduchým výpočtem vycházela na 10, napsal tam 0. A občas se samozřejmě také stalo, že se někdo jednoduše spletl. Software s tím samozřejmě má počítat a pokud nevychází kontrolní součet, má dávat pouze varování, ne takový vstup nepovolit. Nezdá se mi, že by se rodná čísla s chybnou kontrolní číslicí měnila plošně. Zvlášť když se plošně neřešila ani duplicitní rodná čísla, což je podle mne ještě větší problém. Ale mít rodné číslo s chybnou kontrolní číslicí, to také musela být radost.
19.9.2014 21:42 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Citace s wikipedie (lepší nemám):

Z tohoto pravidla existuje výjimka: pokud je zbytek po dělení devítimístného čísla roven deseti (a neexistuje tedy žádná kontrolní číslice, která by splňovala předchozí podmínku), jako kontrolní číslice se použije nula (a celé rodné číslo pak dělitelné jedenácti není). Například: RČ 840501/1330: 840501133 mod 11 = 10 (a 8405011330 mod 11 = 1). Tato výjimka však byla použita jen zhruba u 1000 RČ, přidělování takových rodných čísel bylo roku 1985 podle interního předpisu FSÚ Č. Vk. 2898/1985 ukončeno; není však vyloučeno, že se v minimálním počtu vyskytla i po tomto roce.

Nevím jestli se měnila plošně, ale za vím, že více lidem a taky vím, že když se touto kontrolou prohnala ≈ 1/6 všech rodných čísel v ČR, tak krom třímístného záčíslí (< 1954) všechna seděla (při tvorbě jisté aplikace, vyvstala otázka jestli to kontrolovat natvrdo a zadavatel si to prověřil ve své DB).

Jen tak mimochodem, RČ lze stejně používat jen do roku 2054, pak ztratí jedinečnost, ale paradoxně ne pro nejstarší RČ, ale až ta od 1954 ;-)

Změnili mi to ještě několik let před tím co jsme si pořídili 386-ku, tedy to nikomu nevadilo, bo nikdo tu dělitelnost nekontroloval, radosti vyvstaly až po změně (např. perem v papírové občance s hvězdičkou a jakousi vysvětlivkou vzadu, na řidičáku na 50ccm jen normálně přeškrkané :)), protože každý čuměl jako trubka, včetně VB a následně policie (býval jsem „pro jistotu“ kontrolován často, protože některé mé aktivity a vzhled nezapadal do škatulky).

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
20.9.2014 08:06 Filip Jirsák
Rozbalit Rozbalit vše Re: Sql primary key
Rodná čísla se ruší už asi tak patnáct let, tak se to do toho roku 2054 snad stihne... Už jsem viděl i desetimístné údajně rodné číslo vydané po roce 1954 osobě, která se na rodila před rokem 1954. Chtěli jsme to nechat prověřit v evidenci obyvatel, ale nevím, jak to dopadlo.

Já ten článek na Wikipedii o rodném čísle neberu moc vážně, protože je tam spousta tvrzení, která se nevyskytují nikde jinde a jsou neozdrojovaná.
20.9.2014 12:01 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Stačí poheldat, existují důvěryhodnější zdroje: MZCR UPO
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.9.2014 20:21 Filip Jirsák
Rozbalit Rozbalit vše Re: Sql primary key
V těch zdrojích se napíše nic o rodných číslech cizinců, v prvním zdroji úplně chybí informace o přičítání 20 k měsíci. Takže článek na Wikipedii do v mých očích nezdůvěryhodňuje. Ale pokud šlo jenom o ten zbytek po dělení deseti, v tom se všechny tři zdroje shodují. Otázka je, zda to jeden neopisuje od druhého. Pokud by to přidávání nuly při zbytku deset bylo opravdu někde kodifikováno a běžně se to používalo, bylo by takových rodných čísel za 35 let řádově více než tisíc. Takže pokud je pravdivá informace o jejich počtu, viděl bych to spíš tak, že to pravidlo během těch pětatřiceti let ne všichni správně pochopili, a až v roce 1985 se v předpise výslovně uvedlo, že takhle tedy ne, a že když se píše o dělitelnosti jedenácti, myslí se tím dělitelnost jedenácti.

Jinak v prvním zdroji je uvedeno, že kontrolní číslice se přidává k rodným číslům osob narozených po 1.1.1954, což je podle mne logické. A je to tak i v zákoně.
20.9.2014 12:05 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Jinak s tím 1954 jsi mě dostal, ale v jiné rovině, vždy jsem bral 1954 jako milník narození dané osoby, ne dobu kdy jí přiděleno rodné číslo a ani mně nenapadlo, že v tom může být rozdíl (chápu že může) a řekl bych, že to tak i posuzovaly úřady, proto k tomu asi došlo.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
24.9.2014 15:46 ivan
Rozbalit Rozbalit vše Re: Sql primary key
mas stesti ze jsi na to prisel takhle brzo. vetsinou na to lidi prijdou az kdyz pozadaji o duchod a teprve pak zjisti, ze cele roky prispivali na duchod nekomu jinemu. pak jim nezbyva nic jineho nez obejit vsechny sve byvale zamestnavatele a vyzadat si od nich podklady o platbach na duchove pojisteni. nastesti za komancu lidi nemenili zamestnavatele tak casto jako je tomu dnes.
13.9.2014 22:39 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Ano? A to chcete, aby při změně se propagovala změna do všech tabulek databáze?

Navíc vytištěné dokumenty jaksi nezměníte, takže staré vytištěné podklady budou problémové atd....

19.9.2014 11:56 tacoberu | skóre: 3
Rozbalit Rozbalit vše Re: Sql primary key
Na úrovni databáze to přeci není problém. A vytištěné dokumenty nejsou součástí databáze. Ostatně, toto jsem zmínil v mém příspěvkou. Možná jsi to přehlédl.
11.9.2014 01:37 neklan | skóre: 11 | blog: neklan_no_clan
Rozbalit Rozbalit vše Re: Sql primary key
Celý ten přiklad je blbost. Člověk nemá unikátní jméno. Člověk má více psů. pes má více lidí. OneToOne, OneToMany, ManyToMany?

Pokud je to celé jenom metafora příklad a alegorie, tak si vyber lepší příklad.
AraxoN avatar 11.9.2014 08:32 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Sql primary key
Za tých 15 rokov čo patlám databázy som vyskúšal kdečo. Najviac sa mi osvedčilo mať úplne v každej tabuľke stĺpec "id" - automaticky generované unikátne celé číslo, ktoré zároveň slúži ako PK. Z hľadiska normálnych foriem databázy to možno občas je no-no, ale ušetrí to dosť práce z dlhodobého pohľadu. Odkazy na takúto tabuľku potom vo valnej väčšine využívajú práve toto "id". Samozrejmosťou by malo byť používanie referencií a vytváranie indexov na väčšine FK stĺpcov.
A fine is a tax for doing wrong. A tax is a fine for doing well.
12.9.2014 16:08 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Jakýkoli významový identifikátor, ať se zadavatel dušuje jak chce, nikdy není unikátní a neměnný. Vždy se nakonec stane, že se najdou dva lidi se stejným RČ, je potřeba nikdy neměnný login změnit, podle původně naprosto nevýznamového osobního čísla se ředitel rozhodne lidi rozřazovat do oddělení, bude třeba do databáze zařadit záznam bez přiděleného identifikátoru atd...

Toť zkušenost z praxe.

Proto silně doporučuji do jakékoli tabulky zavádět umělý PK. Jednak to bude dost často i šetrnější na DB (viz náročnost porovnávání řetězců), jednak to do budoucna ušetří přepisování celé aplikace kvůli změně zadání...
12.9.2014 16:15 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Plus je pro toto chování ještě jeden velmi silný důvod:

Zavést umělé id je rychlé. Zkontrolování (i z hlediska dalšího vývoje aplikace) to, že je identifikátor opravdu neměnný a unikátní je netriviální věc a navíc to nevymyslíš sám, musíš s tím votravovat klienta (opravdu to nebudete nikdy měnit?). Takže řešit něco takovýho má smysl jen v případě, kdy opravdu je těch ušetřenejch pár bytů záležitost života a smrti (když už ne Tvojí, tak aspoň toho db serveru :-))
12.9.2014 17:48 j
Rozbalit Rozbalit vše Re: Sql primary key
Klient ti klidne pisemne potvrdi, ze to nikdy menit nebude, a tyden po predani v ramci zarucniho supportu budes resit, ze se nekde neco posralo, protoze to nekdo zmenil. Osobni zkusenosti ...
Tarmaq avatar 12.9.2014 16:29 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Nevidim jediny rozumny duvod, proc by napr. v enumech musel byt umely primarni klic.
Don't panic!
12.9.2014 22:25 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Prvním z důvodů je snažší refaktoring. Velmi často změní položka enumu význam, a je snažší ji přejmenovat.

Druhým z důvodů je to, že dosti často to, co se nejprve tvářilo jako prostý enum, časem nabobtná...
Tarmaq avatar 15.9.2014 09:47 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Prvním z důvodů je snažší refaktoring. Velmi často změní položka enumu význam, a je snažší ji přejmenovat.
Velmi casto? Nevim, ja tohle zas tak casto neresim. Kazdopadne cas, ktery usetrim nepouzitim umeleho PK v enumu prevysuje cas, ktery bych jednou za uherak venoval nejakym upravam.
Druhým z důvodů je to, že dosti často to, co se nejprve tvářilo jako prostý enum, časem nabobtná...
Ani kdyz prosty enum casem nabobtna, nemusi prece prijit o lidsky srozumitelny primarni klic ne?

Je to asi otazka osobnich preferenci. Ja radsi pracuju s tabulkou, ktera obsahuje na prvni pohled zajimava data, misto vypisu spousty nicnerikajicih cisel.
Don't panic!
16.9.2014 08:25 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Jaký čas? Pro práci s enumem můžeš mít samozřejmě v aplikaci třídu a pracovat s ní transparentně.

Nabobtná jsem nemyslel vertikálně, ale horizontálně - najednou je potřeba k dané položce enumu ukládat další data, protože některé volby mají něco společného atd... a z prostého enumu máš najednou klasickou tabulku.

To sice vypadá jako klad, ale naopak u větších tabulek oceníš kompaktní výpis, kdy se ti např. v konzoli neláme řádek přes několik řádků (nebo se láme aspoň přes málo řádků)
Tarmaq avatar 16.9.2014 09:37 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Sql primary key
Jaký čas? Pro práci s enumem můžeš mít samozřejmě v aplikaci třídu a pracovat s ní transparentně.
Mel jsem na mysli cas, ktery stravim psanim ruznych SQL dotazu. Pokud budu mit tabulky plne cisel, ke kterym je vzdy potreba dojoinovat tabulky s preklady tech cisel, zabere mi to zbytecne cas navic a budu otraveny.
Nabobtná jsem nemyslel vertikálně, ale horizontálně - najednou je potřeba k dané položce enumu ukládat další data, protože některé volby mají něco společného atd... a z prostého enumu máš najednou klasickou tabulku.
Stale nevidim problem v pridani nekolika dalsich sloupcu (napr. preklady hodnoty pro okolni systemy). Co to je "klasicka tabulka"? Preci tabulku neurcuje pocet sloupcu, ale vyznam. U ciselniku vazne nevidim duvod, proc by mely mit umely identifikator. Je s tim akorat prace navic, ale to uz se akorat opakuju..
To sice vypadá jako klad, ale naopak u větších tabulek oceníš kompaktní výpis, kdy se ti např. v konzoli neláme řádek přes několik řádků (nebo se láme aspoň přes málo řádků)
Tak tomuhle vubec nerozumim. Jaky kompaktni vypis? Jako kdyz misto kratkeho srozumitelneho identifikatoru budu mit nicnerikajici cislo, ocenim ze se mi v konzoli nezalomi radek? Tohle jako klad fakt nevnimam.
Don't panic!
15.9.2014 10:14 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Spousta programátorů se enumu prostě bojí. Přitom elegantně řeší obousměrnou konverzi string-číslo včetně reakce na chybné vstupy apod. Přejmenování položky enumu v databázi je jednodušší, než ve všech aplikacích, které s tou databází pracují.

Připadá mi podivné, že by položka enumu měnila význam. Příklad by nebyl?

Nabobtnání enumu se bát nemusíme, běžně je podporováno až 64k položek.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
16.9.2014 08:59 Logik
Rozbalit Rozbalit vše Re: Sql primary key
Přejmenování položky enumu v databázi je jednodušší, než ve všech aplikacích, které s tou databází pracují.
Kdo říká, že se něco přejmenovává v aplikaci? Překlad integer - patřičný název je samozřejmě v databázi. Dokonce tam může bejt překlad i pro každej jazyk použitej v aplikaci...

A jak enum mění význam? Např. změnou legislativy, chybou analýzy, potřebou detailnějšího rozlišení kategorií, atd...

Jinak proti enumu 100% nejsem - ten je podle mne někdy vhodný: pokud jde o párpoložkový naprosto jistě neměnný (to existuje??) enum, který navíc databáze podporuje jako nativní typ, pak to může být dobrá volba. V tom případě to je jednak ale defakto jiný zápis integeru, jednak to nijak nesouvisí s debatou o primárním klíči, protože takový enum zpravidla není primárním klíčem.

V okamžiku, kdy se kvůli tomu musí zakládat další tabulka, nebo kdy je hodnot více než pár, tak podle mne převažují výhody klasické tabulky. Jedna z dalších výhod, která tu např. nepadla je, že do tabulky lze z aplikace něco přidat, do enumu dosti obtížně.

16.9.2014 09:59 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Přejmenování položky enumu v databázi je jednodušší, než ve všech aplikacích, které s tou databází pracují.
Kdo říká, že se něco přejmenovává v aplikaci? Překlad integer - patřičný název je samozřejmě v databázi. Dokonce tam může bejt překlad i pro každej jazyk použitej v aplikaci...
Nebavíme se o striktním enumu ani striktní další tabulce. Pohlaví je enum, kvůli tomu nikdo snad další tabulku nebude zakládat. Barva vozu už je na zvážení, ale tady bych se stále přiklonil k enumu. Vždy je možné barvu přidat nebo ubrat, ale pracovníkovi evidence bych to nedovolil.

Účtovou osnovu bych však jednoznačně udělal jako číselník, ve kterém PK bude string obsahující číslo účtu. Syntetický PK zde nemá místo.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
pavlix avatar 16.9.2014 10:06 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Sql primary key
Barva vozu už je na zvážení, ale tady bych se stále přiklonil k enumu. Vždy je možné barvu přidat nebo ubrat, ale pracovníkovi evidence bych to nedovolil.
To mi připomíná, když jsem kupoval auto, tak ten, kdo mi ho nabízel tvrdil, že je fialové :D, v techičáku to mělo tmavě červenou a po koupi jsem dostal nový techničák, tam už mělo barvu červenou. Takový malý chameleon, když k tomu navíc ještě přidám, že to do nás napálila čerstvá řidička, které zapmněli říct, že se za volantem kouká před sebe, a od té doby mám dva díly ve stříbrné ;).
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
16.9.2014 11:07 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Ad. pohlaví bych už zvolil určitě číselník, protože je to dané legislatiou dané země a účelem (pominu-li, že i fyzično je někdy nejasné ). Legislativně minimálně Němci a Austrálie mají pohlaví tři(, v zásadě to měli už některé kmeny indiánů v severní Americe dávno, i když trochu jinak :-) ). A účelem užití, viz facebook desítky pohlaví v některých zemích.

Ad. Barvu vozu(, po prvních Fordech,) rozhodně není vhodné mít jako enum, protože doplnění barvy do enum-u je zásah do struktury. Nové barva je určitě číselníková položka spravovaná správcem číselníku, ne správcem/tvůrcem DB.

enum je vhodný pro interní stavy/workflow programu, a řekl bych, že není vůbec vhodný na jakákoliv (vnější) data.

PS: Označuji některé věci jako „tvrdý číselník“ (mám proto to prefix hc_), což je sice číselník a kód se může pevně opírat o obsah, takže zásah do něj je třeba dělat s rozumem(, proto nemá ksicht pro správu a jeho obsah může být trvale v programové cache). Možná bych tam před pár lety dal i pohlaví, nyní už určitě ne, ale třeba jednotky hmotnosti objemu a pod. tam prdnu.

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
16.9.2014 11:55 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Ad pohlaví: Vím, že na Venuši je jich sedm :-)
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
16.9.2014 12:13 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
To by jsi měl vědět, že většina bytostí ve vesmíru nestačí dvě a určitě jsi je chtěl takovým enum-em svázat. :-)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.9.2014 12:28 j
Rozbalit Rozbalit vše Re: Sql primary key
Sis docela nabeh ... "Pohlaví je enum, kvůli tomu nikdo snad další tabulku nebude zakládat." Tusim ze v Nemecku bylo nedavno uznano treti pohlavi zcela ofiko ...

Dtto oblibene Ano/Ne ... a pak si nekdo vzpomene, ze tam chce Mozna.

Proc je pak enum naprosta pitomost v 90%? Protoze pokud chces mit system multilang, tak z volby Ano/Ne mas obratem stovky zaznamu.

Uctovaci osnova je pak uz uplne mimo, nekdo si vzpomene ze to bude chtit predelat, at uz z duvodu legislativnich nebo jinych a ses v...
pavlix avatar 22.9.2014 12:32 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Sql primary key
Proc je pak enum naprosta pitomost v 90%? Protoze pokud chces mit system multilang, tak z volby Ano/Ne mas obratem stovky zaznamu.
To jako že dáš jinou hodnotu yes a jinou ano? To je trochu debilita, ne? To, že jsou systémy navržené vícejazyčně zahrnuje i to, že ty jazyky jsou jen věcí prezentace a nikoliv interních struktur, rozhodně ne to, že naplácám všechny jazyky na jednu hromadu a budu nabírat desetijazyčné pracovníky.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
22.9.2014 18:56 j
Rozbalit Rozbalit vše Re: Sql primary key
Pokud dobre vidim, jako hlavni vyhoda enum bylo uvedeno to, ze tam misto int je rovnou hodnota, tedy trebas Ano/Ne.

Pro cinana pak asi bude daleko pochopitelnejsi, kdyz tam bude 1/0 a nekde vedle bude prekladova tabulka, nez kdyz mu tam napisu Ano, ze. Navic se klidne muze stat, ze z onoho Mozna se stane "Spise ne", coz je trivialni vyresit zmenou prekladu, zato casto nemozne vyresit zmenou enum. Co vic, ono se dokonce muze stat, ze z Ano bude Ne. Pricemz hodnota v DB zustane stejna. Staci zmenit nazev pole ve formulari a vyznam muze byt zcela opacny.

A to bude pak opravdu prehledna vec, kdyz v databazi bude napsano Ano, ale na formulari se bude zobrazovat Ne ...

Vse zcela osobni zkusenosti ...

pavlix avatar 22.9.2014 19:48 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Sql primary key
Pokud dobre vidim, jako hlavni vyhoda enum
To asi nebude úplně relevantní k tomu, co jsem psal, že.
Pro cinana pak asi bude daleko pochopitelnejsi, kdyz tam bude 1/0
Jestli bude v nějakém low level nástroji nebo v kódu vidět 1/0, yes/no nebo true/false považuju za nepodstatný implementační detail.
Vse zcela osobni zkusenosti...
Bordel se člověku může objevit všude, že.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
xkucf03 avatar 22.9.2014 20:19 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
Pro cinana pak asi bude daleko pochopitelnejsi, kdyz tam bude 1/0 a nekde vedle bude prekladova tabulka, nez kdyz mu tam napisu Ano, ze.

Hodnoty enumu jsou na stejné úrovni jako názvy tabulek, sloupečků atd. – měly by být stejným jazykem. Lokalizace se řeší na úplně jiné úrovni.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9.2014 20:23 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
Proč do toho stále pleteš jazykové závislosti? Ty se přece řeší až při prezentaci.

Enum bývá implementován jako zkrácený int (1 nebo 2 byty) a čísluje se od jedné. Tedy Ano/Ne je interně uloženo jako 1/2. Vstup a výstup enumu si klidně můžeš udělat číselný, ale nedoporučuji to.

O enumu píšeš jako o něčem, co se jednou nastaví a už se to nesmí modifikovat. To je omyl. Enum se dá normálně změnit.

Místo slov Ano/Ne je obvykle vhodné zvolit pojmy odpovídající typu sloupce, aby to při tabulkovém výpisu trochu vypadalo. Samozřejmě se to musí nechat protéct přes NLS.

Hodnoty Ano/Ne v české podobě jsou obvykle akceptovatelné u programů, které mají pracovat pouze v českém prostředí. Pokud se jen trochu předpokládá mezinárodní použití, anglické pojmy budou jistě vhodnější. Už kvůli jednoduššímu NLS. Není pak problém Číňanovi prezentovat 是還是不是.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
22.9.2014 13:08 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
To je nějaký problém? Tak do toho enumu s pohlavím přidám navíc to německé.

Dtto Ano/Ne. Klidně přidám i Možná.

Multilang nepotřebuji řešit v databázi. To se vyřeší v klientské části aplikace. Po německém kliknutí na "Ja" se na server odešle "Ano" nebo "Yes", pokud to vedeš anglicky. Stejným způsobem přidáš i volbu "Možná". Řešit lokalizaci v serverové části aplikace je poněkud úlet, nemyslíš?

Psal jsem, že účtovou osnovu bych jednoznačně dal do tabulky. Pochopil jsi to snad jinak? Pokud má jakýkoli účet nenulový obrat, tak ho předělat nesmíš. Během roku smíš účty pouze přidávat.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
22.9.2014 15:00 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Ad. Pohlaví: „A i to australské a bude jiné od toho německého nebo to bude stejné?“
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.9.2014 15:20 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: Sql primary key
V obou případech se jedná o "neurčité" pohlaví. Asi neuděláme chybu, když bude stejné.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
22.9.2014 16:19 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key

Ale definice není úplně stejná ;), rozhodě číselník, ať si správce aplikace nastaví jak potřebuje…

OT: Jinak u nás obecně máme problém s „pohlavím“, protože tím velmi často směšujeme dvě často související, ale různé věci „sex“ (masculine/feminine/»neuter«) a „gender“ (male/female/intersex), tedy biologickou příslušnost ze „sociální“ příslušností. Sranda je, že v tom prvním se definují tři a v tom druhém jsou zatím většinou definovány tři. Ale „sex“ a „gender“ nemusí patřit ve sloupcích pod sebe. (Legislativně je něco v pár zemích podchyceno, ovšem různě…)

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.9.2014 18:59 j
Rozbalit Rozbalit vše Re: Sql primary key
Viz Sangala: Definice muze byt jina ;D. A ty to trebas z nejakyho duvodu potrebujes oddelit.

BTW: Kdyz je to nahore zenska a dole chlap, tak to vlastne je co? ;D
22.9.2014 19:50 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Sql primary key
Odpověd:

Sex: X (Australie, myslím Nový Zéland) - nevím jak to označují Němci) - prostě neurčitelný (a nevím co se dává u nás, ale myslím, že doktor určí - ehm, si hodí losem)
Gender: Cokoliv z male, female (Australie: intersex asi značený X nevím, ještě snad unspecified nebo indeterminate).

Problém je, že „intersex“ se někdy spojuje s „Sex“ a legislativně se řeší pokaždé něco jiného, Němci to zavedli kvůli neurčitelnosti pohlaví svých desetitisíců lidi, a už to nemusí řešit ani u dětí. Austálie, podle mně, byla motivována sociální rovinou a až pak nějakým „výkladem“ do toho doplnila i fyziologicky neurčitelné „pohlaví“ (X, znamená i indeterminate/intersex/unspecified). Tedy v Německu je to jen a pouze o nemožnosti určení „sex“, jak se člověk cítí či jak se mu bouří hormony(, jaké máš chromozomy je putna), „ukaž se dole a co vidím, to si“, v Austrálii do toho možeš kecat a dát si „X“.

Je v tom docela zmatek, kdybych to měl udělat poctivě a pro daný účel by nestačilo jen určení jednoho, tak mám v DB Sex a Gender (česky Pohlaví a Gender) a nechám na správci aplikace (číselníku), co tam dá a asi bych vyplnil jen Male/Female (Muž/Źena) a Masculine/Feminine (Mužský/Źenský).
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
xkucf03 avatar 22.9.2014 15:32 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sql primary key
<i> vs. <!>
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.