タグ付けされた質問 「uniqueidentifier」

私は使用する理由としない理由について読んGuidでいintます。 int小さく、速く、覚えやすく、時系列を保持します。そして、Guid私が見つけた唯一の利点は、それがユニークであることです。どちらの場合、a Guidはa よりも優れており、intその理由は？ 私が見たものからint、多くの場合、無関係である数の制限を除いて、欠陥はありません。 なぜ正確にGuid作成されたのですか？実際には、単純なテーブルの主キーとして機能する以外の目的があると思います。（Guid何かに使用する実際のアプリケーションの例は？） （Guid = UniqueIdentifier）SQL Serverのタイプ

97 performance  sql-server  primary-key  uniqueidentifier 

読み取りが多いことがわかっているシステムを設計しています（1分あたり数万回の読み取り）。 names一種の中央レジストリとして機能するテーブルがあります。各行には、textフィールドrepresentationとkeyそのMD5ハッシュである一意のフィールドがありますrepresentation。1現在、このテーブルには数千万のレコードがあり、アプリケーションの存続期間中に数十億に達すると予想されています。 テーブルを参照する他の（スキーマとレコード数が非常に異なる）テーブルは多数ありnamesます。これらのテーブルのいずれかのレコードにname_keyは、機能的にはnamesテーブルへの外部キーであるが含まれることが保証されています。 1：ちなみに、ご想像のとおり、このテーブルのレコードは一度書き込まれると不変です。 テーブル以外の特定のnamesテーブルでは、最も一般的なクエリは次のパターンに従います。 SELECT list, of, fields FROM table WHERE name_key IN (md5a, md5b, md5c...); 読み取りパフォーマンスを最適化したいと思います。私が最初にやるべきことは、インデックスのサイズを最小化することだと思います（ただし、間違っていると証明されてもかまいません）。 質問： /に最適なデータ型は何ですかれるkeyとname_key、列？以上 を使用する理由はありますか？または？hex(32)bit(128)BTREEGIN

35 postgresql  database-design  index  datatypes  uniqueidentifier 

私の同僚が私に興味深い質問を送ってきたが、それは完全には説明できない。 彼はいくつかのコード（以下を含む）を実行し、それからやや予期しない結果を得ました。 本質的に、UniqueIdentifier（これから私が参照するGuid）をbinary（またはvarbinary）タイプに変換するとき、結果の前半の順序は逆になりますが、後半はそうではありません。 私の最初の考えは、システムのエンディアンが原因であり、Guidディスプレイは保存されているが、binaryフォームは保証されていないということでした。 明らかにこれは実装の詳細ですが、それについて適切な説明があったのではないかと思っていました。 コード： declare @guid uniqueidentifier = '8A737954-CBEC-40CE-A534-2AFFB5A0E207'; declare @binary binary(16) = (select convert(binary(16), @guid)); select @guid as [GUID], @binary as [Binary]; 結果： GUID Binary 8A737954-CBEC-40CE-A534-2AFFB5A0E207 0x5479738AECCBCE40A5342AFFB5A0E207 ご覧のとおり、Guid（の最後まで40CE）の前半は各セクションごとに逆方向に保存されています。つまり、の最初のセクションGuidは後方に、次に2番目のセクション、次に3番目のセクションになりますが、セクションの順序は保持されます。その後、最後の2つのセクションは、に表示される正確な順序で保存されGuidます。 誰でもこれを説明できますか？（より大きなテストセットを以下に示します。） コード： declare @guid_to_binary table ( [id] int identity(1,1), [guid] uniqueidentifier, [binary_conversion] binary(16) ); declare @i int = 1; …

17 sql-server  sql-server-2014  uniqueidentifier  uuid 

UNIQUEIDENTIFIERユーザーが特定のデータにアクセスするために使用できるアクセスキーとしてを使用する予定です。その意味で、キーはパスワードとして機能します。 INSERT...SELECTステートメントの一部として、このような識別子を複数生成する必要があります。アーキテクチャ上の理由から、この場合はサーバー側で識別子を生成します。 安全にランダムに生成するにはどうすればよいUNIQUEIDENTIFIERですか？NEWIDセキュリティプロパティがまったく保証されないため、これは十分にランダムではないことに注意してください。推測できないIDが必要なため、SQL ServerのSystem.Security.Cryptography.RandomNumberGeneratorに相当するものを探しています。に基づくものCHECKSUM、RANDまたはGETUTCDATE資格がないもの。

15 sql-server  sql-server-2012  security  uniqueidentifier  cryptography 

この種の質問がたくさん出てくることは知っていますが、この決定を下すのに役立つ説得力のある議論をまだ読んでいません。我慢してください！ 私には巨大なデータベースがあります-それは1日あたり約10,000,000レコード増加します。データはリレーショナルであり、パフォーマンス上の理由から、BULK COPYでテーブルをロードします。このため、行のキーを生成する必要があり、IDENTITY列に依存することはできません。 64ビット整数（bigint）は使用するのに十分な幅がありますが、一意性を保証するには、IDを作成するための集中ジェネレーターが必要です。私は現在、サービスがXシーケンス番号を予約し、衝突がないことを保証するようなジェネレーターサービスを持っています。ただし、この結果は、私が持っているすべてのサービスがこの1つの集中ジェネレーターに依存しているため、システムの配布方法が制限され、他の依存関係（ネットワークアクセスの要求など）に満足できませんこの設計によって。これはときどき問題になりました。 プライマリGUID（SQLの外部で生成される）としてシーケンシャルGUIDを使用することを検討しています。私自身のテストで確認できた限り、これらの唯一の欠点は、より広いデータ型のディスク領域のオーバーヘッドです（インデックスでの使用により悪化します）。bigintの選択肢と比較して、クエリのパフォーマンスが目に見えるほど遅くなることはありません。BULK COPYを使用したテーブルのロードはわずかに遅くなりますが、それほどではありません。GUIDベースのインデックスは、シーケンシャルGUID実装のおかげで断片化されていません。 基本的に、私が知りたいことは、私が見落としているかもしれない他の考慮事項があるかどうかです。現時点では、私は飛躍してGUIDを使い始めたいと思っています。私は決してデータベースの専門家ではないので、どんなガイダンスでも大歓迎です。

14 sql-server  primary-key  uniqueidentifier 

私の開発者は、ほとんどすべてのテーブルでGUIDをPKとして使用するようにアプリケーションを設定しており、デフォルトでSQL ServerはこれらのPKでクラスター化インデックスを設定しています。 システムは比較的新しく、最大のテーブルは100万行を超えていますが、インデックス作成を検討しており、近い将来必要に応じて迅速にスケーリングできるようにしたいと考えています。 したがって、私の最初の傾向は、クラスター化インデックスを、DateTimeのbigint表現である作成済みフィールドに移動することでした。ただし、CXを一意にできる唯一の方法は、このCXにGUID列を含めることです。ただし、最初に作成されます。 これにより、クラスタリングキーの幅が広がりすぎて、書き込みのパフォーマンスが向上しますか？読み取りも重要ですが、書き込みはおそらくこの時点で大きな懸念事項です。

13 sql-server  index-tuning  clustered-index  uniqueidentifier 

私は、一意のIDを明示的に生成するUDFからPRIMARY KEY、Identity Columnsを使用する方が良いかどうかについて議論しています。 Identity列について議論しています。 私のパートナーは、手動で値を生成することを主張しています、と彼は主張します UDFを作成できる別のテーブルにUDFを配置する リソースをロックする ID_Valueによって呼び出される1つのフィールドでIDテーブルをインクリメントする1 これをグローバル一意識別子として使用します またはid+1、挿入時にテーブルに 識別制約のないサーバーや環境間でデータを移動する方が簡単です。データがあるDBから、ステージングデータやダミーデータなどの別の類似のDBに移動する。非本番環境でのテストでは、すべてのレコードを昨日からテスト用のステージングまで引き下げたい場合があります。 どの実装がより意味がありますか？

11 sql-server  sql-server-2005  functions  identity  uniqueidentifier 

ロギングから遅延相関まで、さまざまな理由で、システムでUUIDをしばらく使用しています。私が使用したフォーマットは、次のように単純になったときに変化しました。 VARCHAR(255) VARCHAR(36) CHAR(36) BINARY(16) BINARY(16)パフォーマンスを基本的な自動インクリメント整数と比較し始めたのは、最後に到達したときです。テストとその結果を以下に示すが、あなただけの要約をしたい場合は、それがあることを示しているINT AUTOINCREMENTとBINARY(16) RANDOM（データベースが前の試験に事前に入力された）200000までの範囲のデータで同じ性能を有します。 私は当初、UUIDを主キーとして使用することに懐疑的でしたが、実際にはまだそうですが、両方を使用できる柔軟なデータベースを作成する可能性はここにあります。多くの人がどちらか一方の利点を強調しますが、両方のデータ型を使用することで相殺される欠点は何ですか？ PRIMARY INT UNIQUE BINARY(16) このタイプの設定の使用例は、システム間の関係に一意の識別子が使用される、テーブル間の関係の従来の主キーです。 私が本質的に発見しようとしているのは、2つのアプローチの効率の違いです。追加のデータが追加された後はほとんど無視できる使用される4倍のディスク容量に加えて、それらは同じように見えます。 スキーマ： -- phpMyAdmin SQL Dump -- version 4.0.10deb1 -- http://www.phpmyadmin.net -- -- Host: localhost -- Generation Time: Sep 22, 2015 at 10:54 AM -- Server version: 5.5.44-0ubuntu0.14.04.1 -- PHP Version: 5.5.29-1+deb.sury.org~trusty+3 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; …

11 mysql  database-design  performance  uniqueidentifier 

次のsqlfiddleを見てください：http ://sqlfiddle.com/#!2/dacb5/1 CREATE TABLE contacts ( id int auto_increment primary key, name varchar(20), network_id int, network_contact_id int ); INSERT INTO contacts (name, network_id, network_contact_id) VALUES ('John', 4, 10), ('Alex', 4, 11), ('Bob', 4, 12), ('Jeff', 4, 45), ('Bill', 7, 11), ('Walter', 7, 45), ('Jessie', 7, 360) ; 連絡先の基本的な表があります。フィールドは、他のテーブルにリンクID番号が含まれています。network_idnetwork_contact_id INSERT IGNOREこのテーブルに対してクエリを実行できるようにしたいのですが、network_idとの組み合わせを、network_contact_id照合する一意のキーとして使用したいと考えています。 …

9 mysql  insert  unique-constraint  uniqueidentifier 

ゴール テーブルに値を挿入した後、リアルタイムで最新のGUID値を取得します 問題 それを行う方法がわからない 情報 コードは住所と郵便番号の新しい値のみを指定する必要があります テーブルには多くのデータが含まれる可能性があります テーブル CREATE TABLE [AddressBook] ( [testID] [uniqueidentifier] NOT NULL default newid(), [address] [nvarchar](50) NULL, [zipcode] [nvarchar](50) NULL )

8 sql-server  t-sql  default-value  uniqueidentifier 

最近、職場でデータベースでリレーションシップがどのように定義されるかを知り、これが標準的な方法であるかどうか疑問に思いました。 プロセスAとプロセスBの2つのプロセスがあるとします。プロセスBはプロセスAの結果に依存するため、プロセスBの実行とプロセスAの実行の間に定義する必要がある関係があります。これが関係の定義方法です。 TableProcessA: Id そして TableProcessB: Id ProcessAId さて、これまでのところ、私には物事は理にかなっていますが、それから、私とテーブルのデザインに対する私の理解が少し奇妙になっています。TableProcessAまたはTableProcessBで行が作成されるたびに、それぞれに対してグローバルに一意のIDを作成する関数が呼び出されます。そのため、基本的に、Idはテーブルだけでなくデータベース全体に対しても一意であるため、TableProcessAおよびTableProcessBのすべてのIdフィールドには一致が含まれません。 私の質問は、これはどのくらい標準的ですか？各テーブルには、データベース全体ではなく、テーブルに固有の自動インクリメントIDが必要であるという考えに思いつきました。

8 database-design  uniqueidentifier