| Autor | Zpráva | ||
|---|---|---|---|
| JardaB Profil |
#1 · Zasláno: 31. 7. 2019, 08:51:22
Zdravím,
jak lze vyřešit následující? Mám jakoukoliv tabulku, kde každý den zapíšu cca 300 tis záznamů a cca 50-200 tis smažu. Rád bych vyřešil sloupec 'id' - auto_increment tak, aby nové záznamy vyplnily ty smazané. V současné době mám id jako datový typ INT a nechci to prostě hlídat a měnit datový typ na vyšší. |
||
| RastyAmateur Profil |
#2 · Zasláno: 31. 7. 2019, 09:02:54
JardaB:
Nemyslím si, že to jde a ani jsem to nenašel. Hlavně to je podle mě špatně, protože tím by to vlastně ztratilo ten charakter identifikátoru, když by to každý den ukazovalo na něco jiného... Potřebuješ v těch svých datech vůbec ID? Nemůžeš si ten identifikátor poskládat například z kombinace zbylých sloupečků? |
||
| blaaablaaa Profil |
JardaB:
Do INT unsigned nacpeš max číslo 4294967295, při zápisu 300 000 záznamů denně bude INT stačit na 39 let. |
||
| JardaB Profil |
blaaablaaa:
před týdnem to bylo cca 10-50 tis, nyní to je 50-200 tis. Za měsíc to bude mnohem více. Takže ve finále může dojít k přetečení do několika let i méně. Jde o herní systém a závisí na počtech hráčů. Jen mne napadlo, že se to nějak řeší. RastyAmateur: ID určitě potřebuji, zbylá data jsou jen statistická data, která mi nedají identifikátor. Pravděpodobně to asi řeším zbytečně, ale děkuji za Vaše názory... |
||
| Kajman Profil |
#5 · Zasláno: 31. 7. 2019, 09:25:19
Použijte bigint, je to jeden alter příkaz, id nerecyklujte.
|
||
| blaaablaaa Profil |
#6 · Zasláno: 31. 7. 2019, 09:25:25
JardaB:
ID je od toho, aby bylo unikátní - recyklace id je špatný přístup. Pokud máš strach, že to přeteče, použij BIGINT. Nebo bude možná chyba v návrhu databáze, případně to třeba půjde řešit jinak. |
||
| Tomášeek Profil |
JardaB:
ID potřebuješ (k identifikaci záznamu), ale zároveň recyklací ty záznamy nebudou jednoznačně identifikovatelné. Ono teda je i otázkou, o jaké záznamy se jedná a jestli je nutné ty staré mazat. Nevíš, kdy se ti jednou sebraná data mohou v budoucnu hodit. Jediným řešením je navýšení datového typu na bigint (unsigned) s velikostí 18 446 744 073 709 551 615. To při pár záznamech denně na nějaký pátek vystačí. Změnu datového typu můžeš provést klidně hned, ať na to nemusíš za pár let myslet a do té doby denně kontrolovat a klepat se :-)
|
||
| JardaB Profil |
#8 · Zasláno: 31. 7. 2019, 09:52:48
Pokud BIGINT nějak neovlivní svižnost dotazů, tak přepnu. Zkusím to případně otestovat na vykonstruovaných datech. Počítám, že rozdíl bude zanedbatelný nebo žádný..
|
||
| blaaablaaa Profil |
JardaB:
Tabulka bude o něco větší, takže i výkon půjde dolů. Základ u návrhu db je používat nejmenší/nejprimitivnější možný datový typ, který ti vyhovuje. Pokud reálně očekáváš takový nárůst záznamů, použij klidně BIGINT. Ale myslím, že než se dostaneš na takový počet záznamů, budeš určitě řešit i nějaké další optimalizace. |
||
|
Časová prodleva: 5 let
|
|||
0