アカウント名:
パスワード:
たとえば、IDを64ビットにして、上位16bitは発行日のUNIX時間の下位16bit、次の32bitはOpenSSLライブラリで作った疑似乱数、次の16bitはOSの疑似乱数発生機能で作った疑似乱数とかにすれば絶対被らない
何故、ぼくのかんがえたさいきょうのIDがバグ・非効率の原因になるということを理解できないのだろう……。
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
「ぼくのかんがえたさいきょうのID」の生成規則はエンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。# N社ってコーユー怪奇的な仕様が大好きだよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
IDは十分長くしておけばランダムIDでも被らない (スコア:1)
たとえば、IDを64ビットにして、
上位16bitは発行日のUNIX時間の下位16bit、
次の32bitはOpenSSLライブラリで作った疑似乱数、
次の16bitはOSの疑似乱数発生機能で作った疑似乱数
とかにすれば絶対被らない
Re: (スコア:0)
何故、ぼくのかんがえたさいきょうのIDが
バグ・非効率の原因になるということを理解できないのだろう……。
逆じゃないかな (スコア:0)
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
Re:逆じゃないかな (スコア:0)
「ぼくのかんがえたさいきょうのID」の生成規則は
エンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。
# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。
# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって
# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。
# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)
# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが
# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。
# N社ってコーユー怪奇的な仕様が大好きだよね。