アカウント名:
パスワード:
たとえば、IDを64ビットにして、上位16bitは発行日のUNIX時間の下位16bit、次の32bitはOpenSSLライブラリで作った疑似乱数、次の16bitはOSの疑似乱数発生機能で作った疑似乱数とかにすれば絶対被らない
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
元コメのように時刻情報を入れたいならTwitterのsnowflakeだな
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のほうが生成個所を分散出来る分データサイズの問題除けば断然いい。
シーケンスのことであってます。非技術者にシーケンス言っても何それ？の説明→イチャモンのキッカケになりがちなんで使うクセが…回数増えると時間の溶けっぷりがバカにならないからさ…スマヌ。
ていうかまさにRDBのユニークキーを独自実装しようとして痛い目見たケース
何故、ぼくのかんがえたさいきょうのIDがバグ・非効率の原因になるということを理解できないのだろう……。
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
「ぼくのかんがえたさいきょうのID」の生成規則はエンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。# N社ってコーユー怪奇的な仕様が大好きだよね。
F通だからですよ。
F通のPJ部長が、WindowsとLinuxでSHA256算出結果が違うかもしれないとか言い出して、YESマンのテクニカルアドバイザ(藁)が肯定して独自実装となった。
確認と称して、数ギガ単位の文字列(失笑)を出して突き合わせてテスト完了とか本当にクソ。文字列の理由は、証跡を紙に出して顧客提出する必要があるからだそうで。
つ 誕生日のパラドックス
被らなくなるまで再生成すればいいような単純な話ではないのか
被らないチェックにかかる時間がどんどん長くなっていくわけですね。しかも、IDの生成が並行処理もできず、ボトルネックになるという。
衝突多すぎでしょ生成アルゴリズムを考え直した方がいいのでは
前もって人数分作ってプールしとけばええんや。
誰か一人がまとめて生成するんならそもそも連番でいい。
あ。ユーザ的には連番でもいい感じなの？助かる。
で、プールから同じ番号を平行して取り出すんですね。
採番って結構面倒なんだから巨大なデータに大量の同時アクセスってのが感覚として解らない奴が独自実装するなっての。
単純にテーブルのPKにシーケンスやらIdentity設定すりゃ完了だよ
よーし長ければいいんだねあれなら完璧！
じゅげむじゅげむ
あれ？
手抜きせずにちゃんと全部書け！
実装次第でミリ秒まで同じアクセス時刻なら被るんじゃ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
IDは十分長くしておけばランダムIDでも被らない (スコア:1)
たとえば、IDを64ビットにして、
上位16bitは発行日のUNIX時間の下位16bit、
次の32bitはOpenSSLライブラリで作った疑似乱数、
次の16bitはOSの疑似乱数発生機能で作った疑似乱数
とかにすれば絶対被らない
Re:IDは十分長くしておけばランダムIDでも被らない (スコア:1)
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
Re: (スコア:0)
元コメのように時刻情報を入れたいならTwitterのsnowflakeだな
Re: (スコア: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)
シーケンスのことであってます。
非技術者にシーケンス言っても何それ？の説明→イチャモンのキッカケになりがちなんで使うクセが…
回数増えると時間の溶けっぷりがバカにならないからさ…
スマヌ。
Re: (スコア:0)
ていうかまさにRDBのユニークキーを独自実装しようとして痛い目見たケース
Re: (スコア:0)
何故、ぼくのかんがえたさいきょうのIDが
バグ・非効率の原因になるということを理解できないのだろう……。
逆じゃないかな (スコア:0)
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
Re: (スコア:0)
「ぼくのかんがえたさいきょうのID」の生成規則は
エンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。
# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。
# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって
# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。
# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)
# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが
# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。
# N社ってコーユー怪奇的な仕様が大好きだよね。
Re: (スコア:0)
F通だからですよ。
F通のPJ部長が、WindowsとLinuxでSHA256算出結果が違うかもしれないとか言い出して、
YESマンのテクニカルアドバイザ(藁)が肯定して独自実装となった。
確認と称して、数ギガ単位の文字列(失笑)を出して突き合わせてテスト完了とか本当にクソ。
文字列の理由は、証跡を紙に出して顧客提出する必要があるからだそうで。
Re: (スコア:0)
つ 誕生日のパラドックス
Re: (スコア:0)
被らなくなるまで再生成すればいいような単純な話ではないのか
Re: (スコア:0)
被らないチェックにかかる時間がどんどん長くなっていくわけですね。
しかも、IDの生成が並行処理もできず、ボトルネックになるという。
Re: (スコア:0)
衝突多すぎでしょ
生成アルゴリズムを考え直した方がいいのでは
Re: (スコア:0)
前もって人数分作ってプールしとけばええんや。
Re: (スコア:0)
誰か一人がまとめて生成するんならそもそも連番でいい。
Re: (スコア:0)
あ。ユーザ的には連番でもいい感じなの？助かる。
Re: (スコア:0)
で、プールから同じ番号を平行して取り出すんですね。
採番って結構面倒なんだから巨大なデータに大量の同時アクセスってのが感覚として解らない奴が独自実装するなっての。
Re: (スコア:0)
単純にテーブルのPKにシーケンスやらIdentity設定すりゃ完了だよ
Re: (スコア:0)
よーし長ければいいんだね
あれなら完璧！
じ
ゅ
げ
む
じ
ゅ
げ
む
あれ？
Re: (スコア:0)
手抜きせずにちゃんと全部書け！
Re: (スコア:0)
実装次第でミリ秒まで同じアクセス時刻なら被るんじゃ？