アカウント名:
パスワード:
たとえば、IDを64ビットにして、上位16bitは発行日のUNIX時間の下位16bit、次の32bitはOpenSSLライブラリで作った疑似乱数、次の16bitはOSの疑似乱数発生機能で作った疑似乱数とかにすれば絶対被らない
この手のものは独自仕様で実装すると痛い目見るのでちゃんとUUIDとか使いましょう。
uuidも重い。
DB的にはint64のオートnoで一意にしとけばいい。これより軽いモノは今は無いかと。
それとは別にuuidみたいなコード振りたいなら、noとコードを1:1で持つテーブル用意すりゃ良い。分けときゃコードを遅延発行してもデータの関係性には一切影響なく処理続行出来る。
テーブル連結も数値故軽くできルールもシンプルにでき、dbmsもとくに縛りなく出来る。変更も容易い。
もしint64の約900京の一意性で足りんならint128にすれば良いさ。
オートNoはなぁ。投入結果がわかるやつならいいけどね。シーケンスとか。
つーかオートナンバーってAccess以外で聞いたことないんだけど。
シーケンスのことであってます。非技術者にシーケンス言っても何それ?の説明→イチャモンのキッカケになりがちなんで使うクセが…回数増えると時間の溶けっぷりがバカにならないからさ…スマヌ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
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: (スコア:0)
オートNoはなぁ。投入結果がわかるやつならいいけどね。シーケンスとか。
つーかオートナンバーってAccess以外で聞いたことないんだけど。
Re:IDは十分長くしておけばランダムIDでも被らない (スコア:0)
シーケンスのことであってます。
非技術者にシーケンス言っても何それ?の説明→イチャモンのキッカケになりがちなんで使うクセが…
回数増えると時間の溶けっぷりがバカにならないからさ…
スマヌ。