Portál AbcLinuxu, 25. dubna 2024 13:27
jako prim. key nastavit sloupec jmenoJmeno jako JEDNOZNACNY identifikator? IMHO docela hloupe...
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?
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).
12.9.2014 09:39
okbob | skóre: 30
| blog: systemakuv_blog
| Benešov
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í)?
Š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)
13.9.2014 07:52
okbob | skóre: 30
| blog: systemakuv_blog
| Benešov
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í.
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).
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?
22.9.2014 15:06
Pavel Stárek | skóre: 44
| blog: Tady bloguju já :-)
| Kolín
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
22.9.2014 16:09
Pavel Stárek | skóre: 44
| blog: Tady bloguju já :-)
| Kolín
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ě.
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“.
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)
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ží.Tak to je složený klíč
(dodavatel, ean)
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.
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.
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.
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ě 
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 modifikovatMně 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…
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)
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.
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.
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?
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.
10.9.2014 18:25
11.9.2014 22:44
12.9.2014 11:24
12.9.2014 14:26
19.9.2014 12:15
... 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í.
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.
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.
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.
UPDATE t
SET id = id + 1
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.
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.
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) :).
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.
ALTER TABLE table
RENAME id TO private_id,
ADD id INTEGER ;
UPDATE table SET id = private_id ;
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.
INSERT INTO "comment" (id_post, "order", title) VALUES
(
42,
(SELECT COALESCE(MAX("order"), 0) + 1 FROM "comment"),
'Lorem ipsum.'
);
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?
Jednak by v tom vnořeném dotazu měla být podmínka na článekSamozř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).
order rikat identifikator, ale budiz.Vazba mezi komentářem a článkem je M:N? Stejný komentář může být pod více články? Proč vazební tabulka?
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.
(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).
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
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.
)?
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)
) v pořádku.
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:
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ů
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í?
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].
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
Např. seo-slug je záhodno měnitAby odkazy přestaly fungovat? Tak to je SEO za všechny prachy.
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.
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í.
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á.
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ší.
.
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.
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).
11.9.2014 08:32
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
)
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.
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.
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ě.
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.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...
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é ;).
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.
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.
Pokud dobre vidim, jako hlavni vyhoda enumTo asi nebude úplně relevantní k tomu, co jsem psal, že.
Pro cinana pak asi bude daleko pochopitelnejsi, kdyz tam bude 1/0Jestli 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.
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.
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ě…)
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ý).
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.