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

dboスキーマに関しては： データベースオブジェクトを作成するときにdboスキーマを使用しないことはベストプラクティスですか？ なぜdboスキーマを避けるべきなのですか？ どのデータベースユーザーがdboスキーマを所有する必要がありますか？

29 sql-server  sql-server-2008  schema  best-practices 

私は非常に安全な環境で作業することに慣れているため、非常に細かい粒度で権限を設計します。私が通常行うことの1つは、更新されるべきではない列DENYに対する機能を明示的にユーザーに提供するUPDATEことです。 例えば： create table dbo.something ( created_by varchar(50) not null, created_on datetimeoffset not null ); これらの2つの列は、値が設定されたら変更しないでください。したがって、私は明示的にそれらDENYのUPDATE許可をします。 最近、チームミーティング中、開発者は、「何らかの理由で値を更新する必要がある場合」に、フィールドが更新されないことを保証するロジックをデータベース層ではなくアプリケーション層に含めるべきであると指摘しました。私にとっては、典型的な開発者のメンタリティのように聞こえます（私は知っています、私は以前は1人でした！） 私は会社のシニアアーキテクトであり、アプリを機能させるために必要な最小限の特権の原則に常に取り組んできました。すべての許可は定期的に監査されます。 このシナリオのベストプラクティスは何ですか？

25 sql-server  database-design  permissions  best-practices 

ソフトウェア開発者向けにテーブルとリレーションを設計するチームがあります。私たちの組織では、彼らは3NF正規化の実施について非常に厳しいです。正直に言うと、私たちの組織の規模と、ニーズやクライアントが時間とともにどのように変化するかを考えると同意します。設計決定の背後にある理由について明確になっていない領域は、アドレスのみです。 これは主に米国の住所に焦点を当てていますが、これはこれを行うすべての国に当てはまると思います。住所の各部分は、住所テーブルの独自の列を取得します。たとえば、この厄介な米国の住所を使用します。 Attn: Jane Doe 485 1/2 N Smith St SW, APT 300B Chicago, IL 11111-2222 次のようにデータベース内で分割されます。 番地：485 ストリートフラクション：1/2 ストリートプレディレクショナル：N（北） 通りの名前：スミス 通りのタイプ：ST（通り） ストリートポスト方向：SW（南西） 市：シカゴ 州：IL（イリノイ州） 郵便番号：11111 Zip4コード：2222 国（米国を想定） 注意：ジェーンドゥ 私書箱：NULL 住居の種類：APT（アパート） 住居番号：300B また、田舎のルートと契約ルートに関連する他の列がいくつかあります。さらに、特定のアプリケーションには、いくつかの国際アドレスが含まれている可能性があります。データモデラーは、国際住所に固有の列を追加すると述べました。これは通常の行1、行2のフィールドです。 最初は、これはWAYオーバーボードだと思いました。オンラインで繰り返し調べるとは、住所1、2、3、場合によっては4を使用してから、都市、地域、郵便番号を分割することです。この粒度が有益な新しいアプリケーションのユースケースが1つあります。ユーザーが重複したビジネスを作成していないことを検証する必要があり、住所の確認は検証の1つです。私たちはできるアドレスライン1と2で動作するようにそれを得るが、それはより困難になるであろう。 特定のアプリケーションに関しては、ビジネスと人々（物理、郵送、出荷など）のために複数の種類のアドレスを保存する必要があります。我々は可能性がある印刷可能な形式の文字を生成する必要がありますが、その要件は、これまで議論されていません。 組織内のアプリケーションがサポートする必要があるその他の事項： 監査（完全な履歴テーブルを使用） 宛名ラベルの印刷 印刷フォームの生成 報告（国および地方政府向け） 私たちのアプリケーションは、他のすべてのアプリケーションが行っていることをすべて行っているわけではありませんが、アドレスを複数のコンポーネントに分割することは、私が働いている企業標準です。アプリケーションがその恩恵を受けるかどうかに関係なく、私たちはこれを強制されます。 半関連のStackOverflowの質問：閉じられた良いアドレスパーサーはどこにありますが、アドレスの解析がどれほど難しいかを示しています。 私が彼らの設計決定をよりよく理解し、アイデアでクライアントを売るために... 住所を個々の列に分割すると、どのような問題が解決しますか？ 問題が発生したため、このようなシステムを実装した人にとってのボーナスポイント。

24 database-design  normalization  best-practices  address 

MS SQL Serverインスタンスをホストしているサーバーを再起動するときにデータの破損を防ぐために必要な特別な手順はありますか？ たとえば、最近、SQLサービスを手動で停止するという推奨事項に出会いました。私の理解では、これはWindows shutdownプロセスによって処理されます。 先ほど述べたように、個人が推奨する無数のステップがあると確信していますが、時代遅れのまたは迷信的な慣行を繰り返したくないのです。マイクロソフトからの推奨事項、または広範な業界標準はありますか？ この質問は、マシンを再起動する短期的な手順に関連しています。マシンを永久に停止する前に、マシンが使用されていないことを確認する長期的な手順に関して別の質問があります。

23 sql-server  best-practices  shutdown 

従来、セキュリティのベストプラクティスの一環として、SQL Serverへの接続にデフォルトポートを使用しないことが推奨されてきました。単一のデフォルトインスタンスを持つサーバーでは、デフォルトで次のポートが使用されます。 SQL Serverサービス-ポート1433（TCP） SQL Server Browserサービス-ポート1434（UDP） 専用管理接続-ポート1434（TCP） 質問： このアドバイスはまだ関係がありますか？ 上記のすべてのポートを変更する必要がありますか？

21 sql-server  security  best-practices  dynamic-ports 

データベースまたはアプリケーションのコード部分で外部キーを定義する方が良いでしょうか？

21 database-design  best-practices  foreign-key 

マスターオブインフォメーションサービスの学生向けのDBMSコースでこれを学習したことを覚えています。入力を節約するために、次のように入力できます。 SELECT t1.id, t2.stuff FROM someTable t1 INNER JOIN otherTable t2 ON t1.id=t2.id ; しかし...ストアドプロシージャなどでこれが受け入れられるのはなぜですか？非常に短い時間を節約しながら、ステートメントの可読性を損なうだけであるようです。これを行う機能的または論理的な理由はありますか？曖昧さを削除するのではなく、追加するようです。この形式を使用するために私が見ることができる唯一の受け入れられる理由はFROM someTable idsTable、テーブル名が十分に説明的でない場合に、意味的に意味のあるエイリアスを追加していた場合です。 テーブルのエイリアシングは悪い習慣ですか、これは単に有用なシステムの誤用ですか？

21 stored-procedures  best-practices  naming-convention 

1つのテーブルに250MMの行があり、ほとんどのクエリで結合する別のテーブルに15MM未満の行があるWebサイトを実行します。 サンプル構造： MasterTable (Id, UserId, Created, Updated...) -- 15MM Rows DetailsTable (Id, MasterId, SomeColumn...) -- 250MM Rows UserTable (Id, Role, Created, UserName...) -- 12K Rows これらすべてのテーブルに対していくつかのクエリを定期的に行う必要があります。1つは、無料ユーザー（最大1万人の無料ユーザー）の統計を取得することです。 Select Count(1) from DetailsTable dt join MasterTable mt on mt.Id = dt.MasterId join UserTable ut on ut.Id = mt.UserId where ut.Role is null and …

17 join  best-practices 

私は、SQL Server 2008 r2のデータコレクターを介して2週間、ファイルの増加を監視しています。データベースは、約35（MB）/日で一貫して成長しています。DBは初期サイズの2 GBにまだ達していません。 DBファイルの自動拡張は5MBに設定されています。別のアプローチを試してみたいので、提案やコメントを探しています。 毎週日曜日の夜1:30 AMに実行されるチューニングタスクがあります。タスクは： データベースの整合性を確認する ログファイルを圧縮する-（ログモードがシンプルなので、これは問題ありません） データベースの縮小 インデックスの再編成 インデックスを再構築 統計を更新する 履歴をクリーンアップする 毎週の調整計画にさらに2つのステップを追加したいと思います。 使用領域が特定のしきい値または合計サイズに達した場合、データベースファイルを500 MB増やします。 使用されているスペースが合計サイズの特定のしきい値に達すると、ログファイルを250 MB（縮小後）増やします。 オフラインの時間に成長の負担をかけることにより、高負荷時の自動成長イベントの数を減らしてパフォーマンスを向上させたいと考えています。 自動拡張ファイルに関する質問が2つあります。 ファイルの成長ステップを配置する最適な場所は、現在のステップの前か後ですか？ を使用しALTER DATABASE|MODIFY FILEてファイルを拡大すると、どうすれば判断できSpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)ますか？

16 sql-server  sql-server-2008  sql-server-2008-r2  transaction-log  best-practices 

RAID（安価なディスクの冗長アレイ）には、さまざまな構成（RAID-0、RAID-1 ...）が付属しています。Oracleデータベースをインストールするときにセットアップして使用する推奨RAID構成は何ですか。データベースは、主にデータウェアハウスとして使用されます。

16 oracle  best-practices 

SQL Server 2012 Standard Editionを使用しています。また、Ola Hallengrenのスクリプトを使用して、バックアップとメンテナンスを行うための簡単で柔軟なフレームワークを提供することもあります。 この質問は、オラのスクリプトに関するものではなく、ベストプラクティスに関するものです。究極の答えは「あなたの会社の要件に依存する」ことです。しかし、私は会社の要件について理解したことをどのように実現するのが最善かについて、コミュニティのアドバイスを求めています。 15分ごとにトランザクションログのバックアップを設定したい。このようにして、15分以内のデータが失われることを願っています。ALL_DATABASESを使用する1つのジョブをセットアップする必要がありますか？または、データベースごとに1つのジョブを設定し、それらをすべて並行して開始する方が良いでしょうか？私は、バックアップがシリアルで開始されるというオラのスクリプトの機能をどのように見ているかに基づいているので、私は尋ねます。シリアルの欠点は、連続する各バックアップが他のバックアップが完了するまで待機することです。これにより、バックアップ間の時間が長くなる可能性があります（15分以上）。さらに、1つのバックアップで障害が発生すると、他のバックアップが停止するのではないかと心配になります。そのようなことはしたくありません。他の人にバックアップを続けてほしい。 それでは、Olaのスクリプトがシリアルで実行され、失敗が連続したバックアップを停止するというのは本当ですか？ そして、データベースごとに仕事をする方が良いでしょうか？またはすべてを行う単一のジョブですか？私の傾向は、別々の仕事に向かうことですが、SQL Server DBAの一般的な傾向を理解したいと思います。

15 sql-server  backup  best-practices  ola-hallengren 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はアイントホーフェンのフォンティス大学の学生です。現在、SQL Serverツールの開発を支援するために一連のインタビューを実施しています。この分野の専門家からフィードバックをもらいたいと思います。 私の質問の1つは次のとおりです。 ベストプラクティスのSQL Serverメンテナンスプランはどのようなものですか？これにはSQL Serverメンテナンスプランを使用しますか、それともカスタムスクリプトを使用しますか？

15 sql-server  best-practices  maintenance 

ルックアップテーブル（またはコードテーブルと呼ばれることもあります）は、通常、特定の列に指定できる値のコレクションです。 たとえば、次のparty2つの列を持つ（政党に関する情報を保存するための）というルックアップテーブルがあるとします。 party_code_idn、システム生成の数値を保持し、（ビジネスドメインの意味を欠いて）実際のキーの代理として機能します。 party_codeは、ビジネスドメインの意味を持つ値を保持するため、テーブルの実際のキーまたは「自然な」キーです。 そして、そのようなテーブルは以下のデータを保持しているとしましょう： +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ party_code値は「共和党」と「民主党」を続けるの列は、テーブルの実際のキーであること、UNIQUE制約に設定されているが、私は必要に応じて添加party_code_idnし、論理的に言えば、ものの（表のPKとしてそれを定義しました、party_codeプライマリキー[PK]として機能する場合があります）。 質問 トランザクションテーブルからルックアップ値を指すためのベストプラクティスは何ですか？FOREIGN KEY（FK）参照を確立する必要があります（a）自然で意味のある値を直接参照するか、（b）値を代理しますか？ オプション（a）、たとえば +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis …

14 database-design  foreign-key  primary-key  best-practices 

バックグラウンド 私は、約4人のプログラマーと4人のデザイナーから成る小規模なWebチーム向けに新しい開発プロセスの作成に取り組んでいます。将来的にチームを成長させる可能性があることは明らかです。当社の製品は、当社が設計およびホストするクライアントWebサイトを強化する中央アプリケーションです。 以前は、1つの開発データベースを使用して、開発サーバーでFTPを介して作業していました。それは「働いた」*私たちのプロセスを成熟する時間ですので、しばらくの間、私たちは新たな方向に動いています。 Percona Server 5.5を使用していますが、これはデータベースにとらわれず、コストを低く抑えることを考えたものでなければなりません。 目標： 私は、以下を念頭に置いて、データベース開発のための継続的インテグレーション（CI）プロセスの作成を検討しています。 開発者には、開発コードを実行するためのデータのローカルコピーがあります データベース構造を以前の変更セットにロールバックできる 新機能スキーマの変更とスキーマ設計修正の変更を区別できる テストのためにデータベース構造をローカルで変更可能 初期コンセプト SVNとLiquiBaseを使用して以下のプロセスをスケッチしましたが、完全に削除され#4ます。 トランクから「開発」ブランチを作成する 中央の「開発」データベースサーバーは「開発」ブランチから実行されます ローカル開発者は、開発ブランチのスレーブとしてセットアップされます（#1上記を提供） LiquiBaseをチェンジは（この開発サーバーへのスレーブとして動作しているローカルマシンにトリクルダウンします）中央開発用データベースを更新するために、ポストcommitフックを実行する開発ブランチに定期的にコミットしている（LiquiBaseをが提供する#2上で） 機能またはスキーマの修正がQAに進む準備ができたら、DBA（me）は開発ブランチからトランクに適切な変更をマージします。この行為は、ステージングデータベースサーバーに適用するSQLスクリプトを作成します。 ステージングサーバーはTRUNKを反映する必要があります。TRUNKは、本番と同じ構造に加えて、QAにある変更を含む必要があります ステージングサーバーでsqlスクリプトを実行した後、変更に対していくつかのQAを実行します。 すべてが正常に見える場合は、構造にタグを付けます。これにより、DBAによって本番環境で手動で実行される.sqlスクリプトが生成されます（必要に応じてオフピーク時間）。 このプロセスでは、すべての開発者が同じ「開発」ブランチから実行する必要があります。つまり、データベーススキーマのバージョンは常に1つだけです（これが必要かどうかはわかりません）。 また、スキーマへの変更はローカルでテストできず、正しく行わないと他の開発者に影響を与える可能性があります。この環境では、開発者は新しいテーブルを追加するかもしれませんが、既存の構造を変更することはめったにありません。DBAとして、設計修正は私によって行われます。しかし、修正をローカルでテストできないことは、プロセスの最大の問題です。 上記のプロセスを微調整して、ローカル開発を可能にしながら、データの比較的最新のコピーを維持するにはどうすればよいですか（提案されたプロセスの複製によって提供されます）。先週までデータを最新にする必要はありません。 *「働いた」とは、それで十分であるが、PITAだったことを意味します。

14 best-practices  development 

私は既存のプロジェクトで作業を開始し、前の開発者は、テーブルを、スキーマは同じでもデータが異なる10個の個別のテーブルに分割していました。 テーブルは次のようになります。 [tableName_0] [tableName_1] [tableName_2] [tableName_3] [tableName_4] [tableName_5] [tableName_6] [tableName_7] [tableName_8] [tableName_9] 主キーは整数idフィールドです。アプリケーションは、ハッシュアルゴリズム（idmod 10）を使用して、ルックアップ時にアクセスするテーブルを認識します。たとえばid= 10に生じるであろう[tableName_0]。 合計すると、テーブルにはおそらく100,000行あり、成長率は比較的低くなります。 だから、私の質問は、これが実行可能な解決策であるかどうか、それがどんな状況でも良い方法であるかどうかです。私の理論は、それらを組み合わせるようにプッシュすることですUNION。主な欠点は、すべてのアプリケーションコードを変更することと、長期的に見ても価値があるかどうかです。

14 mysql  database-design  best-practices