アカウント名:
パスワード:
たとえば、IDを64ビットにして、上位16bitは発行日のUNIX時間の下位16bit、次の32bitはOpenSSLライブラリで作った疑似乱数、次の16bitはOSの疑似乱数発生機能で作った疑似乱数とかにすれば絶対被らない
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
uuidも重い。
DB的にはint64のオートnoで一意にしとけばいい。これより軽いモノは今は無いかと。
それとは別にuuidみたいなコード振りたいなら、noとコードを1:1で持つテーブル用意すりゃ良い。分けときゃコードを遅延発行してもデータの関係性には一切影響なく処理続行出来る。
テーブル連結も数値故軽くできルールもシンプルにでき、dbmsもとくに縛りなく出来る。変更も容易い。
もしint64の約900京の一意性で足りんならint128にすれば良いさ。
まあそうなんだけど、ぶっちゃけ雇用調整助成金のオンライン申請システムなんて1時間に何アクセスあるんだかみたいなシステムなら、ID採番に10秒かかろうがどうということは無いという。
…いや、何でそんな普通に作っても性能的に全く問題ない筈のシステムで、ID重複なんて珍しいことをやらかしたのかほんと意味わからんけど。
厚生労働省は知らないけど、既存のシステム真似た作り(実は手作業データパッチで設計バグ誤魔化してる)のオチだと思いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
IDは十分長くしておけばランダムIDでも被らない (スコア:1)
たとえば、IDを64ビットにして、
上位16bitは発行日のUNIX時間の下位16bit、
次の32bitはOpenSSLライブラリで作った疑似乱数、
次の16bitはOSの疑似乱数発生機能で作った疑似乱数
とかにすれば絶対被らない
Re: (スコア:1)
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
Re: (スコア:0)
uuidも重い。
DB的にはint64のオートnoで一意にしとけばいい。これより軽いモノは今は無いかと。
それとは別にuuidみたいなコード振りたいなら、noとコードを1:1で持つテーブル用意すりゃ良い。
分けときゃコードを遅延発行してもデータの関係性には一切影響なく処理続行出来る。
テーブル連結も数値故軽くできルールもシンプルにでき、dbmsもとくに縛りなく出来る。変更も容易い。
もしint64の約900京の一意性で足りんならint128にすれば良いさ。
Re:IDは十分長くしておけばランダムIDでも被らない (スコア:0)
まあそうなんだけど、ぶっちゃけ雇用調整助成金のオンライン申請システムなんて1時間に何アクセスあるんだかみたいなシステムなら、ID採番に10秒かかろうがどうということは無いという。
…いや、何でそんな普通に作っても性能的に全く問題ない筈のシステムで、ID重複なんて珍しいことをやらかしたのかほんと意味わからんけど。
Re: (スコア:0)
厚生労働省は知らないけど、既存のシステム真似た作り(実は手作業データパッチで設計バグ誤魔化してる)のオチだと思いますよ。