アカウント名:
パスワード:
たとえば、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重複なんて珍しいことをやらかしたのかほんと意味わからんけど。
厚生労働省は知らないけど、既存のシステム真似た作り(実は手作業データパッチで設計バグ誤魔化してる)のオチだと思いますよ。
UUIDは、分散システムで合意形成とか排他制御をせずに、各ノードが勝手にIDを生成しても衝突しないことが(確率的に)保証されているのが利点。単体の生成処理が遅くても、ノードを増やせば生成速度もスケールする。RDBMSで性能が足りるのなら、分散システムで処理する必要はないし、UUIDを使う意味もない。
オートNoはなぁ。投入結果がわかるやつならいいけどね。シーケンスとか。
つーかオートナンバーってAccess以外で聞いたことないんだけど。
SQLiteのAUTOINCREMENTとか?でもシーケンスの類って大抵キャッシュさせるから必ずしも連番にはならんだろ。させないと性能悪いし。
まぁシーケンスもあまり使いたくないけどな。DBMSがボトルネックになりやすいし、運用がマトモでないとリストア他で直ぐとらぶる。もっとも運用があれだとシーケンス以前ではあるんだけど・・・UUIDのほうが生成個所を分散出来る分データサイズの問題除けば断然いい。
シーケンスのことであってます。非技術者にシーケンス言っても何それ?の説明→イチャモンのキッカケになりがちなんで使うクセが…回数増えると時間の溶けっぷりがバカにならないからさ…スマヌ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
IDは十分長くしておけばランダムIDでも被らない (スコア:1)
たとえば、IDを64ビットにして、
上位16bitは発行日のUNIX時間の下位16bit、
次の32bitはOpenSSLライブラリで作った疑似乱数、
次の16bitはOSの疑似乱数発生機能で作った疑似乱数
とかにすれば絶対被らない
Re: (スコア:1)
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
Re:IDは十分長くしておけばランダムIDでも被らない (スコア:0)
uuidも重い。
DB的にはint64のオートnoで一意にしとけばいい。これより軽いモノは今は無いかと。
それとは別にuuidみたいなコード振りたいなら、noとコードを1:1で持つテーブル用意すりゃ良い。
分けときゃコードを遅延発行してもデータの関係性には一切影響なく処理続行出来る。
テーブル連結も数値故軽くできルールもシンプルにでき、dbmsもとくに縛りなく出来る。変更も容易い。
もしint64の約900京の一意性で足りんならint128にすれば良いさ。
Re: (スコア:0)
まあそうなんだけど、ぶっちゃけ雇用調整助成金のオンライン申請システムなんて1時間に何アクセスあるんだかみたいなシステムなら、ID採番に10秒かかろうがどうということは無いという。
…いや、何でそんな普通に作っても性能的に全く問題ない筈のシステムで、ID重複なんて珍しいことをやらかしたのかほんと意味わからんけど。
Re: (スコア:0)
厚生労働省は知らないけど、既存のシステム真似た作り(実は手作業データパッチで設計バグ誤魔化してる)のオチだと思いますよ。
Re: (スコア:0)
UUIDは、分散システムで合意形成とか排他制御をせずに、
各ノードが勝手にIDを生成しても衝突しないことが(確率的に)保証されているのが利点。
単体の生成処理が遅くても、ノードを増やせば生成速度もスケールする。
RDBMSで性能が足りるのなら、分散システムで処理する必要はないし、UUIDを使う意味もない。
Re: (スコア:0)
オートNoはなぁ。投入結果がわかるやつならいいけどね。シーケンスとか。
つーかオートナンバーってAccess以外で聞いたことないんだけど。
Re: (スコア:0)
SQLiteのAUTOINCREMENTとか?
でもシーケンスの類って大抵キャッシュさせるから必ずしも連番にはならんだろ。
させないと性能悪いし。
まぁシーケンスもあまり使いたくないけどな。DBMSがボトルネックになりやすいし、運用がマトモでないとリストア他で直ぐとらぶる。
もっとも運用があれだとシーケンス以前ではあるんだけど・・・
UUIDのほうが生成個所を分散出来る分データサイズの問題除けば断然いい。
Re: (スコア:0)
シーケンスのことであってます。
非技術者にシーケンス言っても何それ?の説明→イチャモンのキッカケになりがちなんで使うクセが…
回数増えると時間の溶けっぷりがバカにならないからさ…
スマヌ。