Diskuze: Identity databaze
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 10 zpráv z 10.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
novější verze EF dávají negativní identity id dokud nedojde k uložení do databáze. je možné tedy, že se ti to uklád někde samo při ukončování.. negativní index u identity u objektů se používá poměrně často, aby jsi věděl, že jde o nově vkládaný objekt.
Děkuji za odpověď, už jsem myslel, že nikdo nezareaguje. Jde mi o to že, při zadání nového id do tabulky a jeho následného tisku, je místo (např. id145) na listu id-1. A nevěděl jsem, jestli tam mám jenom něco blbě nastavenýho. Ale bude to asi složitější, aby to fungovalo, jak chci. Každopádně děkuji za info!
Tak přece nakonec to byl jenom blbě nastavený autoincrement. Nastavoval jsem to jinde, než bylo potřeba. Ale ještě mám jeden problém! Pokud do databáze řádky vkládám, tak ID je o.k. (vždy o jednu větší), ale když poslední řádek vymažu, tak se ID o -1 neodečte a při dalším novým řádku je o jeden větší a místo toho vymazanýho je díra. (1,2,4,5....)
Ano, tak databáze pracuje. Na starý id může být nejde odkaz a podobně, proti se nikdy id neopakují.
Pokud je to ID jako primární klíč tak to je v pořádku, ID by se nemělo "recyklovat". Jde totiž o to že v jiné tabulce můžeš mít uloženou nějakou položku s vazbou na ID z té první tabulky (cizí klíč). Pokud bys vymazal záznam např. s ID = 2 a pak tam vložil nějaký úplně jiný záznam zase s ID = 2, vznikla by ti relace se záznamem který ukazoval na tu původní položku před vymazáním a to nedává smysl. Spojily by se ti 2 záznamy které spolu nesouvisejí.
Na SQL serveru to jde nějakým příkazem "setřást" aby tam nebyly ty mezery, ale nevím o nikom že by to v praxi někdo použil. Ty "mezery" jsou standardní a žádoucí chování.
Po delší době se zase vracím a popíšu můj problém s databází. Chci si zakládat karty s nějakými údaji do databáze. Ty karty mít očíslované posputně od 1 až..... Myslel jsem, že použiji na číslování karet ID autoincrement, ale mám problém, když poslední kartu vymažu, tak nové číslo karty se o jednu nezmenší, ale pokračuje dál a tím vznikne díra v číslech. Takže takhle to asi nepůjde. Prosím vás o radu nebo hození lasa, jak to vyřešit! Díky.
Ahoj, pokud potřebuješ aby číselná posloupnost byla bez mezer, tak to
jde řešit několika způsoby. Nepoužívej autoincrement (ten ti tam při
vymazání vytvoří ty mezery), ale vytvoř si ještě jeden sloupec, kde si ty
hodnoty budeš dopočítávat sám. A pokud se jejich pořadová čísla nemají
opakovat, nezapomeň ho označit jako Uniqe (na SQL serveru to najdeš v
indexech).
Pořadové číslo si budeš muset počítat sám, ale musíš si dobře
nastavit logiku, protože může nastat několik případů (vkládání na
konec, odmazání z prostředku a vznik mezer které budeš muset setřást
atd.) Obecně to můžeš řešit buď při vkládání např. pomocí přes
T-SQL a nebo v tomto případě by bylo možná lepší použití triggerů.
Můžu se ale zeptat proč ti tam tolik vadí ty mezery? Tohle řešení není úplně standardní a zbytečně si to tím celé komplikuješ. Pořadí záznamů v jakém byly do databáze vloženy získáš seřazením podle primárního klíče (nesmíš samozřejmě používat to "setřesení", popř. si můžeš do nějakého sloupečku vkládat datum a čas přidání záznamu a řadit to podle něj) a jedinečnost záznamů je dána zase primárním klíčem (a to že tam jsou mezery je úplně fuk, důležité je že je unikátní).
Děkuji za odpověď a vysvětlím to třeba na příkladu seznamu faktur. V databázi jsou uloženy faktury s pořadovými čísly, které se vždy o jedno zvětší, když uložím novou. A potřebuji, aby se při smazání pouze poslední faktury (nikoli někde z prostředka seznamu), pořadové číslo o jedno zmenšilo, aby při další nové faktuře, nebyla v číslech díra. Možná vám připadá můj problém docela malicherný, ale jsem "rookie" a nikde jsem takový tutoriál o databázi, který by tohle řešil nenašel.
Pokud bude povoleno smazání pouze posledního záznamu, tak by to šlo
řešit tak jak jsem popisoval. Nepoužívej autoincrement, ale do nějakého
sloupce (pokud možno označeného jako unique) si číslo vkládej sám.
Vždycky před vložením nového záznamu si vytáhní poslední číslo
(SELECT MAX(poradove_cislo) FROM nazevTabulky) a zvyš si ho o jednu.
Popř. to můžeš řešit pomocí triggerů, ale to by sis musel nastudovat,
pokud s tím nemáš zkušenosti.
Zobrazeno 10 zpráv z 10.
