タグ付けされた質問 「best-practices」

列に個別の値が必要な場合は、制約を使用できます create table t1( id int primary key, code varchar(10) unique NULL ); go または、一意のインデックスを使用できます create table t2( id int primary key, code varchar(10) NULL ); go create unique index I_t2 on t2(code); 一意の制約を持つ列は、一意のインデックスの適切な候補のようです。 一意の制約を使用し、代わりに一意のインデックスを使用しない既知の理由はありますか？

195 sql-server  index  best-practices  constraint  unique-constraint 

開発者は、SELECT本番データベースを照会（/読み取り専用）する許可を与えられるべきですか？私が以前働いていた場所では、開発チームがdb_datareader役割を果たしていました。私が現在働いている場所では、開発チームは実稼働インスタンスに接続することさえできません。 テストインスタンスの1つは、1週間に1回、運用環境のバックアップから復元された運用環境のコピーです。したがって、開発者が実際にデータを表示しても問題はありません。 開発者がプロ​​ダクションにクエリを許可しない理由は何ですか（単に機密データの読み取りにアクセス権を持たせたくない場合を除く）。

162 sql-server  best-practices  permissions 

私はPostgresが初めてで、MySQLデータベースを移行しようとしています。MySQLでは私が付与できSELECT、UPDATE、INSERT、およびDELETE低特権ユーザの権限を、指定したデータベース内のすべてのテーブルに適用するには、これらの助成金を有効にします。Postgresで何かを見逃しているに違いありません。各テーブルにこれらの特権を一度に1つずつ付与する必要があるように見えるからです。多くのデータベースと、データベースごとに数百のテーブルがあるため、地面から降りるのは大変な作業のようです。さらに、データベースが動作し始めると、テーブルの追加が頻繁に発生するため、絶対に必要な場合を除き、毎回アクセス許可を付与する必要はありません。 これはどのように達成されますか？

151 postgresql  best-practices  postgresql-9.1 

私はいくつかのブレント・オザールのビデオを見ています（例えば、このような）、彼はテーブルの前に‘tbl’またはを付けないことを提案してい‘TBL’ます。 インターネット上で、ドキュメントに何も追加されず、「読むのに時間がかかる」というブログを見つけました。 質問と考慮事項 これは本当に問題ですか？なぜなら、最初のdbaジョブ以来、テーブルの前に 'tbl'を付けているからです（シニアDBAから組織のためにそれを行うように言われました）。 これは私が取り除く必要があるものですか？いくつかのテストを行い、非常に大きなテーブルをコピーして「tbl」プレフィックスを付け、もう一方のテーブルはそのままにして、パフォーマンスの問題に気付きませんでした。

92 sql-server  best-practices  naming-convention 

常にトランザクションを作成することは悪い習慣ですか？ たとえば、1つだけのトランザクションを作成することをお勧めしSELECTますか？ トランザクションが本当に必要でない場合、トランザクションを作成するコストはいくらですか？ のような分離レベルを使用している場合でも、READ UNCOMMITTEDそれは悪い習慣ですか？

88 sql-server  best-practices  transaction 

「データベースレイヤーにアプリケーションロジックを配置することに対する、またはそれに対する引数は何ですか？」という質問のdba.seバージョンとProgrammers.seバージョンに関する回答とコメント 一部の職場のDBAとプログラマーの格差について非常に明らかにしています。 このような問題に関してプログラマーとより良く働くために、DBAはどのように異なってできるでしょうか？ 我々がすべき： 特に適切に設計されたデータベースを使用する場合、プログラマーが直面する困難を理解するために使用しているツールと言語を学習しますか？ データベースと、データベースレベルでビジネスロジックを持つことの利点について、プログラマーの教育を強化することをお勧めしますか？ よりプログラマーにとって使いやすいトランザクションAPIを使用するなどして、データへのインターフェイスを定義する方法を変更します（たとえば、後方互換性などの問題のために）。

46 database-design  best-practices 

ストアドプロシージャのパフォーマンス（以前の記事）と使いやすさが疑わしいMySQLのバックグラウンドから来て、私はPostgreSQLを会社の新製品として評価しています。 私がやりたいことの1つは、アプリケーションロジックの一部をストアドプロシージャに移動することです。そのため、ここでは、特にパフォーマンスの落とし穴に関して、PostgreSQL（9.0）で関数を使用する際のDOおよびDO N'T（ベストプラクティス）を求めています。

46 postgresql  best-practices  plpgsql 

私はこれをかなり長い間考えてきました。 基本的な質問は、ストアドプロシージャを単体テストする方法ですか？ 私は、古典的な意味で関数のユニットテストを比較的簡単に設定できることを知っています（つまり、ゼロ個以上の引数を取得して値を返します）。しかし、行をどこかに挿入し、挿入の前後にいくつかのトリガーを使用して、一見単純な手順の実際の例を考慮すると、「ユニット」の境界を定義することさえ非常に困難です。INSERT自分自身だけをテストする必要がありますか？それはかなり簡単です、私は思う-比較的低い値で。イベントチェーン全体の結果をテストする必要がありますか？これが単体テストであるかどうかという質問とは別に、適切なテストを設計することは、多くの追加の疑問符が途中で発生する非常に骨の折れる仕事です。 そして、常にデータが変化するという問題が生じます。UPDATE数行以上の影響がある場合、影響を受ける可能性のあるすべての行を何らかの方法でテストケースに含める必要があります。DELETEsなどに関するさらなる困難など。 それでは、ストアドプロシージャをどのように単体テストしますか？完全に絶望的な複雑さの限界がありますか？メンテナンスにはどのようなリソースが必要ですか？ 編集 AlexKuznetsovの答えに基づくもう1つの小さな質問：または、それが完全に役に立たないという閾値がありますか？

44 best-practices  unit-test 

次のような一般的なフィールドの長さとデータ型に関する最も一般的なベストプラクティスは何ですか？ ファーストネーム 苗字 住所 Eメール 性別 状態 シティ 国 電話番号 等....

44 database-design  best-practices 

ダウンタイムなしでライブデータベースのスキーマをどのように変更しますか？ たとえば、すべてが特定のユーザーに関連付けられている、メールアドレスなどのさまざまなユーザーデータを含むテーブルを持つPostgreSQLデータベースがあるとします。電子メールアドレスを新しい専用テーブルに移動する場合は、スキーマを変更してから、電子メールデータを新しいテーブルに移行する必要があります。元のテーブルへの書き込みを停止せずにこれを行うにはどうすればよいですか？確かに、古いテーブルから新しいテーブルにデータが上書きされる間、新しいデータは引き続き古いテーブルに書き込まれ、失われますよね？ この問題はかなり頻繁に発生すると思いますが、それを処理するための標準的なソリューションが見つかりません。 この記事ではこの問題を扱いますが、手順3を本当に理解していませんでした。彼は両方のテーブルに書き込み、古いデータを最初のテーブルから新しいテーブルに移行するように言っています。古いデータのみを移行していることをどのように確認しますか？ （HerokuでPostgreSQLを使用しています。）

43 postgresql  schema  best-practices  migration  deployment 

私は、SQL Server 2005データベースのメンテナンスプランを考案する必要があります。バックアップについては、毎日15分ごとにデータベースの完全バックアップとトランザクションログバックアップを行いたいと考えています。私が抱えている問題は、他にどのようなタスクをやりたいのか、どのくらいの頻度でそれらを行うべきなのかを把握することです。 それで、これまでのところ私はこれを念頭に置いています。私の考えに欠陥がある場合、またはこれを行うためのより良い方法がある場合は、私を修正してください。 バックアップ-すべてのテーブル、フルバックアップ（毎日） バックアップ-選択したテーブル、フルバックアップ（1時間ごと） バックアップ-トランザクションログ（15分ごと） データベースの整合性を確認する（毎日） インデックスの再編成（毎日） 統計の更新（毎日） データベースの縮小（毎週） インデックスの再構築（毎週） メンテナンスクリーンアップ（毎日） これらのタスクの一部は毎日実行する必要がないか、毎日実行するべきではないことを少し前に（別のジョブで同様の計画を設定したとき）読んだことを思い出しました。どのものに関しては、それは私を免れます。災害時のデータ損失を削減するより良いメンテナンスプランを作成するための少しのガイダンスを使用できますが、ピーク時の実行時にシステムに負担をかけません（そしてパフォーマンスも向上します）。

43 sql-server-2005  best-practices  maintenance  jobs 

ユーザーテーブルとロールテーブルを持つデータベースモデルがあります。最大10の異なる要素へのアクセス（権利）を制御したい。アクセスは、ロールまたは単一のユーザーに付与できます。以下は、ユーザー、ロール、およびアイテムのテーブル定義です。 CREATE TABLE users ( id serial NOT NULL PRIMARY KEY, username character varying UNIQUE, password character varying, first_name character varying, last_name character varying, ... ); CREATE TABLE roles ( id serial NOT NULL PRIMARY KEY, name character varying NOT NULL, description character varying, ... ); CREATE TABLE element_1 ( …

40 database-design  best-practices 

私は上の情報をたくさん発見したものを STATISTICS、次のとおりです。彼らは、彼らがクエリやインデックスから手動または自動で作成する方法を、維持、およびようにしていますか。しかし、私は見つけることができなかったいかなるに関するガイダンスや「ベストプラクティス」の情報それらを作成するには：インデックスからではなく、手動で作成されたSTATISTICSオブジェクトのほうがどのような状況にメリットがあるか。私は手動でフィルターされた統計を作成し、パーティション化されたテーブルのクエリを支援しました（インデックス用に作成された統計はテーブル全体をカバーし、パーティションごとではないためです-brillaint！）インデックスの詳細を必要とせず、インデックスを維持したり、ブロック/デッドロックの可能性を高めたりするコストも必要ありません。 @JonathanFiteはコメントで、インデックスと統計の違いについて言及しました。 インデックスは、テーブル自体とは異なる方法でソートされたルックアップを作成することにより、SQLがデータをすばやく見つけるのに役立ちます。統計は、クエリを満たすために必要なメモリ/労力をSQLが判断するのに役立ちます。 主に質問を明確にするのに役立つからです。 どのようにこのことを知っている（または上の任意の他の技術的な情報はないものを Sとどのように行動しての性質に関連sをSTATISTICS）助けを決定するとき選択するCREATE STATISTICS以上CREATE INDEXの関連が作成されますインデックスを作成するときに、特に、STATISTICSオブジェクトを？どのようなシナリオでは、よりよい持っていることによって提供されることになるだけ STATISTICS情報をしていないインデックスを持ちますか？ 可能な場合、STATISTICSオブジェクトがに比べてより適しているシナリオの実用例があると、非常に便利INDEXです。 私は視覚的な学習者/思考者であるため、最適なタイミングを判断するのに役立つ可能性のある手段として、STATISTICSとINDEXes の違いを並べて確認すると役立つと思いSTATISTICSました。 Thingy PROs CONs ------- ---------- ------------------- INDEX * Can help sorts. * Takes up space. * Contains data (can * Needs to be maintained (extra I/O). "cover" a query). * More chances for blocking / dead-locks. STATISTICS …

38 sql-server  best-practices  statistics  index-statistics 

各SQLステートメントの後にGOステートメントを使用する理由は何ですか？GOはバッチの終了を通知し、ステートメントの評判を許可しますが、ステートメントごとにそれを使用する利点は何ですか。 声明のたびに多くのマイクロソフトのドキュメントなどが使用を開始したか、気づき始めたばかりかもしれません。 また、ベストプラクティスと見なされるものは何ですか？

34 sql-server  performance  t-sql  best-practices 

私を探しています実用的に値を設定するためのガイダンスBUFFERCOUNT、BLOCKSIZEおよび、MAXTRANSFERSIZEのBACKUPコマンド。私は少し調査を行い（以下を参照）、少しテストを行いました。本当に価値のある答えは「まあ、それは...」で始まることを十分に認識しています。私が行ったテストと私が見つけたリソースのいずれかに示されているテスト（以下の方法を参照）に対する私の懸念は、テストが真空で行われることです。ほとんどの場合、他の負荷のないシステムで行われます。 長期的な経験に基づいたこれらの3つのオプションに関する適切なガイダンス/ベストプラクティスに興味があります：数週間または数か月にわたる多くのデータポイント。そして、特定の値を探しているわけではありません。それはほとんどが利用可能なハードウェアの機能だからです さまざまなハードウェア/負荷要因が、実行すべき内容にどのように影響するか。 これらの値がどれもオーバーライドされるべきではない状況はありますか？ すぐに明らかではないこれらのいずれかをオーバーライドするための落とし穴はありますか？メモリーやディスクI / Oを使いすぎていますか？復元操作を複雑にしますか？ SQL Serverの複数のインスタンス（既定のインスタンスと2つの名前付きインスタンス）を実行しているサーバーがあり、3つのインスタンスすべてのバックアップを同時に実行すると、集合（BUFFERCOUNT* MAXTRANSFERSIZE）使用可能なRAMを超えていませんか？可能なI / O競合？ 1つのサーバーで3つのインスタンスを使用し、3つすべてのバックアップを同時に同時に実行する同じシナリオで、各インスタンス内で複数のデータベースのバックアップを同時に実行すると、これらの値の設定にどのように影響しますか？つまり、3つのインスタンスのそれぞれに100個のデータベースがあり、各インスタンスごとに2つまたは3つのバックアップを同時に実行し、6から9のバックアップが同時に実行される場合。（この状況では、いくつかの大きなデータベースではなく、多くの中小規模のデータベースがあります。） これまでに収集したもの： BLOCKSIZE： サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および65536（64 KB）バイトです。[1] デフォルトは、テープデバイスの場合は65536、それ以外の場合は512です[1] CD-ROMへのコピーおよびCD-ROMからの復元を計画しているバックアップを作成する場合は、BLOCKSIZE = 2048 [1]を指定します 単一のディスクに書き込む場合、デフォルトの512で十分です。RAIDアレイまたはSANを使用する場合は、デフォルトまたは65536のどちらが優れているかをテストする必要があります。[13（18ページ）] 手動で設定する場合、値はデータファイルの作成に使用されるブロックサイズ以上でなければなりません。そうでない場合、次のエラーが表示されます。 メッセージ3272、レベル16、状態0、行3 'C：\ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak'デバイスのハードウェアセクターサイズは4096ですが、ブロックサイズパラメーターは互換性のない512のオーバーライド値。互換性のあるブロックサイズを使用してステートメントを再発行します。 BUFFERCOUNT： デフォルト[2]、[8]： SQL Server 2005以降のバージョン： （NumberofBackupDevices * [mystery_multiplier]）+ NumberofBackupDevices +（2 …

33 sql-server  backup  best-practices  maintenance