すべての開発者がデータベースについて知っておくべきことは何ですか？
好むと好まざるとにかかわらず、ほとんどの開発者の多くは、データベースを定期的に使用するか、いつかデータベースを使用する必要があるかもしれません。そして、野生での誤用と悪用の量、および毎日発生するデータベース関連の質問の量を考慮すると、開発者が設計または作業していなくても、開発者が知っておくべき特定の概念があると言っても過言ではありません今日のデータベース。そう：
開発者や他のソフトウェアの専門家がデータベースについて知っておくべき重要な概念は何ですか？
応答のガイドライン：
リストを短くしてください。
回答ごとに1つのコンセプトが最適です。
具体的に。
「データモデリング」は重要なスキルかもしれませんが、正確にはどういう意味ですか？
根拠を説明してください
なぜあなたのコンセプトが重要なのですか？ 「インデックスを使用する」とだけ言ってはいけません。 「ベストプラクティス」に陥らないでください。視聴者を説得して、さらに学習してもらいます。
同意した回答に投票してください。
最初に他の人の答えを読んでください。 1つの上位の回答は、2つの下位の回答よりも効果的なステートメントです。さらに追加する必要がある場合は、コメントを追加するか、オリジナルを参照してください。
個人的にあなたに当てはまらないからといって、何かに投票しないでください。
私たちはすべて異なるドメインで働いています。ここでの目的は、データベースの初心者がデータベースの設計とデータベース駆動型開発について十分に根拠のある十分な理解を得るための方向性を提供することであり、最も重要な肩書きを競うことではありません。
開発者がデータベースについて最初に知っておくべきことは、これです：データベースとは何ですか？それらがどのように機能するのか、どのように構築するのか、データベース内のデータを取得または更新するためのコードをどのように記述するのかではありません。しかし、彼らは何のためですか？
残念ながら、これに対する答えは動いている目標です。 データベースの全盛期、1970年代から1990年代初期にかけて、データベースはデータを共有するためのものでした。データベースを使用していて、学術プロジェクトに関与していたデータや、自分自身を含むリソースを無駄にしていたデータを共有すること。データベースのセットアップとDBMSの飼い慣らしは非常に大きなタスクであったため、投資に見合うように、複数回利用されたデータの観点から見返りを大きくしなければなりませんでした。
過去15年間、データベースは1つのアプリケーションのみに関連付けられた永続データの保存に使用されるようになりました。MySQL 、または Access 、または SQL Server は非常に日常的になっているため、データベースは通常のアプリケーションのほぼ日常的な部分になっています。データの真の価値が明らかになると、最初の限られたミッションがミッションクリープによって押し上げられることがあります。残念ながら、単一の目的を念頭に置いて設計されたデータベースは、エンタープライズ規模でミッションクリティカルな役割にプッシュされ始めると、劇的に失敗することがよくあります。
開発者がデータベースについて学ぶ必要がある2番目のことは、世界のデータ中心のビューです。データ中心の世界観は、ほとんどの開発者がこれまでに学んだものよりも、プロセス中心の世界観とは異なります。このギャップと比較して、構造化プログラミングとオブジェクト指向プログラミングのギャップは比較的小さいです。
開発者が少なくとも概要で学ぶ必要がある3番目のことは、概念データモデリング、論理データモデリング、物理データモデリングを含むデータモデリングです。
概念的なデータモデリングは、データ中心の観点からの実際の要件分析です。
論理データモデリングは、一般に、概念データモデリングで発見された要件に特定のデータモデルを適用することです。リレーショナルモデルは他の特定のモデルよりもはるかに多く使用され、開発者は確実にリレーショナルモデルを学習する必要があります。自明ではない要件に対して強力で関連性のあるリレーショナルモデルを設計することは、簡単な作業ではありません。リレーショナルモデルを誤解すると、適切なSQLテーブルを構築できません。
物理データモデリングは一般にDBMS固有であり、開発者がデータベースビルダーまたはDBAでもない限り、詳細に学習する必要はありません。開発者が理解する必要があるのは、物理データベース設計を論理データベース設計から分離できる範囲と、物理設計を微調整するだけで高速データベースを作成できる範囲です。
開発者が次に学習する必要があるのは、速度（パフォーマンス）が重要であり、設計の良さの他の尺度がさらに重要であることですデータベースの範囲を修正し、将来的に拡張するか、プログラミングを簡素化します。
最後に、データベースをいじる人は、データの値がそれをキャプチャしたシステムよりも長持ちすることをしばしば理解する必要があります。
ふう！
良い質問。以下は、順不同のいくつかの考えです。
少なくとも2番目の正規形への正規化は不可欠です。
カスケードの削除と更新を適切に考慮する場合、参照整合性も不可欠です。
チェック制約の適切な使用。データベースにできるだけ多くの作業を行わせます。
データベースと中間層コードの両方にビジネスロジックを分散させないでください。できれば中間層コードで、どちらかを選択してください。
主キーとクラスター化キーの一貫したアプローチを決定します。
インデックスをオーバーしないでください。インデックスを賢明に選択してください。
一貫したテーブルおよび列の命名。標準を選択し、それに固執します。
NULL値を受け入れるデータベース内の列の数を制限します。
トリガーに夢中にならないでください。彼らはその用途を持っていますが、急いで物事を複雑にすることができます。
UDFには注意してください。これらはすばらしいものですが、クエリで呼び出される頻度に気付いていない場合、パフォーマンスの問題を引き起こす可能性があります。
データベース設計に関するCelkoの本を入手してください。男は慢ですが、彼のものを知っています。
まず、開発者はデータベースについて知っておくべきことがあることを理解する必要があります。 SQLを挿入して結果セットを取得するだけの魔法のデバイスではなく、独自のロジックと癖を備えた非常に複雑なソフトウェアです。
第二に、異なる目的のために異なるデータベース設定があること。利用可能なデータウェアハウスがある場合、開発者がオンライントランザクションデータベースから履歴レポートを作成することは望ましくありません。
第三に、開発者は結合を含む基本的なSQLを理解する必要があります。
これを過ぎると、開発者がどれだけ密接に関与しているかに依存します。私は、DBAが開発者であり事実上のDBAであり、DBAがちょうど通路を歩いていて、DBAが自分の地域で仕事をしていない仕事で働いてきました。 （私は3番目が嫌いです。）開発者がデータベース設計に関与していると仮定します。
基本的な正規化、少なくとも最初の3つの正規形を理解する必要があります。それ以上のものは、DBAを取得してください。米国の法廷での経験のある人（およびランダムなテレビ番組はここでカウント）には、「キー、キー全体に依存し、キーのみに依存するので、Coddを助けてください」というニーモニックがあります。
インデックスについての手がかりが必要です。つまり、必要なインデックスと、パフォーマンスにどのように影響する可能性があるかを把握する必要があります。これは、無駄なインデックスがないことを意味しますが、クエリを支援するためにそれらを追加することを恐れないことを意味します。それ以上（バランスなど）は、DBAに残しておく必要があります。
データの整合性の必要性を理解し、データを検証している場所と、問題が見つかった場合に何をしているのかを示す必要があります。これはデータベースにある必要はありません（ユーザーに意味のあるエラーメッセージを発行するのは困難です）が、どこかにある必要があります。
計画を取得する方法と、一般的な計画の読み方に関する基本的な知識が必要です（少なくとも、アルゴリズムが効率的かどうかを判断するには十分です）。
彼らは、トリガーが何であるか、ビューが何であるか、そしてデータベースの断片を分割することが可能であることを漠然と知っているべきです。彼らはどんな種類の詳細も必要としませんが、これらのことについてDBAに尋ねるために知る必要があります。
もちろん、プロダクションデータやプロダクションコードなどに干渉しないことを知っている必要があり、すべてのソースコードがVCSに送られることを知っている必要があります。
間違いなく忘れていましたが、実際のDBAが手元にあれば、平均的な開発者はDBAである必要はありません。
基本的なインデックス作成
インデックスのないテーブル、またはデータベース全体、または任意のインデックスまたは無用のインデックスを見ると、いつもショックを受けます。 designingデータベースではなく、いくつかのクエリを記述する必要がある場合でも、少なくとも以下を理解することが重要です。
- データベースにインデックス付けされているものとされていないもの：
- スキャンのタイプの違い、それらの選択方法、クエリの作成方法がその選択にどのように影響するか。
- カバレッジの概念（なぜ
SELECT *）; - クラスター化インデックスと非クラスター化インデックスの違い。
- インデックスが多い/大きいことが必ずしも良いとは限らない理由。
- 関数でフィルター列をラップしないようにする必要がある理由。
設計者は、一般的なインデックスアンチパターンにも注意する必要があります。次に例を示します。
- Accessアンチパターン（すべての列に1つずつインデックスを付ける）
- Catch-Allアンチパターン（すべてまたはほとんどの列の1つの大規模なインデックス。これらの列のいずれかを含む考えられるすべてのクエリを高速化するという誤った印象の下で明らかに作成されます）。
データベースのインデックス作成の品質、および作成するクエリでそれを利用するかどうかは、パフォーマンスの最も重要な部分であるはるかにを考慮しています。 SOに投稿された10個の質問のうち9個、およびパフォーマンスの低下を訴える他のフォーラムは、常にインデックス作成の不足または引数なしの式によるものであることが判明しました。
正規化
正規化されたデザインでは完全に単純な（ "地域ごとの総売上を表示"）という非常に複雑なクエリを書くのに苦労している人を見るのはいつも憂鬱です。
最初にこれを理解し、それに応じて設計すれば、後で多くの苦労を省くことができます。正規化した後、パフォーマンスのために非正規化するのは簡単です。最初からそのように設計されていないデータベースを正規化するのはそれほど簡単ではありません。
少なくとも、3NFとは何か、そしてそこに到達する方法を知っている必要があります。ほとんどのトランザクションデータベースでは、これはクエリを記述しやすくすることと、良好なパフォーマンスを維持することのバランスが非常に優れています。
インデックスの仕組み
これはおそらく最も重要ではありませんが、間違いなく最も過小評価されているトピックです。
インデックス付けの問題は、通常、SQLチュートリアルではまったく言及されておらず、すべてのおもちゃの例がインデックスなしで機能することです。
さらに経験のある開発者は、「 インデックスによりクエリが高速化されます 」よりもインデックスに関する知識がなくても、かなり優れた（そして複雑な）SQLを書くことができます。
これは、SQLデータベースがブラックボックスとして機能する非常に良いジョブを行うためです：
必要なものを教えてください（gimme SQL）、私がそれを引き受けます。
そして、それは正しい結果を取得するために完全に機能します。 SQLの作成者は、システムが舞台裏で何をしているのかを知る必要はありません。すべてがすっごく滑らかになるまで.....
インデックス作成がトピックになるときです。しかし、それは通常非常に遅く、誰か（一部の会社？）はすでに本当の問題に苦しんでいます。
だからこそ、私は、インデックス作成がデータベースを操作するときに忘れてはならない第1のトピックであると信じています。残念ながら、それを忘れるのはとても簡単です。
免責事項
引数は、私の無料の電子書籍「 序文 」から引用されています。「 インデックスを使用、ルーク 」。インデックスがどのように機能し、それらを適切に使用する方法を説明するのにかなりの時間を費やしています。
観察結果を指摘したいだけです。つまり、回答の大部分は、データベースがリレーショナルデータベースと互換性があると想定しているようです。オブジェクトデータベース、フラットファイルデータベースもあります。手元のソフトウェアプロジェクトのニーズを評価することが重要です。プログラマーの観点からは、データベースの決定は遅れる可能性があります。一方、データモデリングは早期に達成でき、多くの成功につながります。
データモデリングは重要なコンポーネントであり、比較的古い概念であると思いますが、ソフトウェア業界の多くの人が忘れていました。データモデリング、特に概念モデリングは、システムの機能的な動作を明らかにすることができ、開発のロードマップとして信頼することができます。
一方、必要なデータベースのタイプは、環境、ユーザーボリューム、およびハードドライブ領域などの利用可能なローカルハードウェアを含むさまざまな要因に基づいて決定できます。
[〜＃〜] sql [〜＃〜]injection を回避し、データベースを保護する方法
すべての開発者は、これがfalseであることを知っている必要があります。「データベース操作のプロファイリングは、コードのプロファイリングとはまったく異なります。」
伝統的な意味で明確なBig-Oがあります。 EXPLAIN PLAN（または同等のもの）アルゴリズムが表示されています。いくつかのアルゴリズムはネストされたループを伴い、[〜＃〜] o [〜＃〜]（n^ 2）です。他のアルゴリズムにはBツリールックアップが含まれ、[〜＃〜] o [〜＃〜]（nlogn）。
これは非常に深刻です。インデックスが重要である理由を理解することが重要です。これは、速度と正規化と非正規化のトレードオフを理解する上で重要です。データウェアハウスがトランザクションの更新に対して正規化されていないスタースキーマを使用する理由を理解することが重要です。
使用されているアルゴリズムが不明な場合は、次の手順を実行します。やめる。クエリ実行プランを説明します。それに応じてインデックスを調整します。
また、当然の結果として、より多くのインデックスは良くありません。
ある操作に焦点を当てたインデックスは、他の操作を遅くすることがあります。 2つの操作の比率に応じて、インデックスを追加すると、良い効果が得られたり、全体的な影響がなかったり、全体的なパフォーマンスが低下したりする場合があります。
すべての開発者はデータベースには異なるパラダイムが必要を理解する必要があると思います。
データを取得するクエリを作成するときは、セットベースのアプローチが必要です。インタラクティブな背景を持つ多くの人々がこれに苦労しています。それでも、彼らがそれを受け入れるとき、彼らは反復焦点の心で最初にそれ自体を提示したものではないかもしれませんが、彼らははるかに良い結果を達成することができます。
素晴らしい質問です。見てみましょう、最初に、誰も結合を完全に理解していないデータベースに問い合わせることを考えるべきではありません。それは、ハンドルとブレーキがどこにあるかを知らずに車を運転するようなものです。また、データ型と最適なデータ型を選択する方法を知る必要があります。
開発者が理解する必要があるもう1つのことは、データベースを設計するときに留意すべき3つのことです。
データの整合性-データが信頼できない場合、本質的にデータがない-これは、他の多くのソースがデータベースにアクセスする可能性があるため、必要なロジックをアプリケーションに配置しないことを意味します。データの整合性を確保するには、制約、外部キー、および場合によってはトリガーが必要です。あなたはそれらが好きではないか、それらを理解するのに悩まされたくないので、それらを使用することを怠らないでください。
パフォーマンス-パフォーマンスの低いデータベースをリファクタリングすることは非常に難しく、最初からパフォーマンスを検討する必要があります。同じクエリを実行する方法は数多くあり、ほとんどの場合、より高速であることが知られています。これらの方法を学習して使用しないことは近視眼的です。クエリまたはデータベース構造を設計する前に、パフォーマンスチューニングに関する本をいくつか読んでください。
セキュリティ-このデータは会社の生命線であり、盗まれることのある個人情報も頻繁に含まれています。 SQLインジェクション攻撃、詐欺、個人情報の盗難からデータを保護する方法を学びます。
データベースを照会するとき、間違った答えを取得するのは簡単です。データモデルを完全に理解してください。多くの場合、実際の決定はクエリが返すデータに基づいて行われます。間違っていると、間違ったビジネス上の決定が下されます。あなたは悪いクエリから会社を殺すか、大きな顧客を失うことができます。データには意味があり、開発者はしばしばそれを忘れているようです。
データは決して消滅することはありません。データを今日どのように取得するかではなく、データを長期間保存するという観点で考えてください。 10万件のレコードがあったときに正常に機能したデータベースは、10年後にはあまり良くないかもしれません。アプリケーションがデータと同じくらい長く続くことはめったにありません。これが、パフォーマンスのための設計が重要な理由の1つです。
データベースには、おそらくアプリケーションが見る必要のないフィールドが必要です。レプリケーションのGUID、日付挿入フィールドなど。など。また、変更の履歴と変更者を保存し、この倉庫から悪い変更を復元できるようにする必要があります。更新にwhere句を付け忘れてテーブル全体を更新する問題を修正する方法をWebサイトに尋ねる前に、これをどのように行うかを考えてください。
本番バージョンよりも新しいバージョンのデータベースで開発しないでください。実稼働データベースに対して直接開発することは絶対にしないでください。
データベース管理者がいない場合は、誰かがバックアップを作成しており、それらを復元する方法を知っていることを確認し、復元のテストを行ってください。
データベースコードはコードです。コードの残りの部分と同様に、ソースコードを保持しない理由はありません。
進化的データベース設計。 http://martinfowler.com/articles/evodb.html
これらのアジャイル手法により、データベース変更プロセスを管理、予測、およびテストすることができます。
開発者は、バージョン管理、継続的な統合、および自動化されたテストの観点から、本番データベースのリファクタリングに必要なものを知っておく必要があります。
進化的データベース設計プロセスには管理上の側面があります。たとえば、このコードベースのすべてのデータベースで一定期間が経過すると、列が削除されます。
少なくとも、データベースリファクタリングの概念と方法が存在することを知っています。 http://www.agiledata.org/essays/databaseRefactoringCatalog.html
分類とプロセスの説明により、これらのリファクタリングにもツールを実装できます。
技術的な詳細の多くはここでカバーされていると思うので、追加したくありません。私が言いたいことの1つは、技術的なことよりも社会的なことです。アプリケーション開発者としての「最高の知識を備えたDBA」のforに陥らないでください。
クエリのパフォーマンスに問題がある場合は、問題の所有権も取得してください。独自の調査を行い、DBAにプッシュして、何が起こっているのか、そのソリューションが問題にどのように対処しているのかを説明してください。
あなたが研究を行った後も、あなた自身の提案を考え出してください。つまり、データベースの問題をDBAに任せるのではなく、問題に対する協力的な解決策を見つけようとします。
リレーショナルデータベースに関する私の経験から、すべての開発者は次のことを知っておく必要があります。
-さまざまなデータ型：
正しいジョブに正しいタイプを使用すると、DB設計がより堅牢になり、クエリが高速になり、作業が楽になります。
-1xMとMxMについて学ぶ：
これは、リレーショナルデータベースの基本です。 1対多および多対多の関係を理解し、必要に応じて適用する必要があります。
-" K.I.S.S。 "原則はDBにも適用されます：
シンプルさが常に最適です。 DBがどのように機能するかを学習していれば、メンテナンスや速度の問題につながる不必要な複雑さを回避できます。
-インデックス：
あなたがそれらが何であるかを知っていれば、それは十分ではありません。それらをいつ使用すべきか、また使用すべきでない場合を理解する必要があります。
また：
- ブール代数はあなたの友達です
- 画像：DBに保存しないでください。理由を聞かないでください。
- SELECTでDELETEをテストする
DBAと開発者/設計者/建築家の両方が、ビジネスドメインを適切にモデル化する方法と、そのビジネスドメインモデルを正規化されたデータベース論理モデル、最適化された物理モデル、適切なオブジェクト指向クラスモデル。各モデルはさまざまな理由で（異なる場合があります）異なり、いつ、なぜ、どのように（異なるべきである）かを理解します。
シンプルな敬意。
- 単なるリポジトリではありません
- おそらくベンダーやDBAよりもよく知らないでしょう
- 午前3時にそれをサポートしません。
Walter M.の回答に対する次のコメントについて：
「非常によく書かれています！そして、その時点でデータベースの仕事をしていない人（つまり私）にとって歴史的観点は素晴らしいです」。
歴史的な観点は、ある意味で絶対的に重要です。 「歴史を忘れる人は、それを繰り返す運命にある。」 Cfr XMLは過去の階層的な誤りを繰り返し、グラフデータベースは過去のネットワークの誤りを繰り返し、OOシステムはユーザーに階層モデルを強制しますが、脳のほんの10分の1でさえ誰もが知っているべきです階層モデルは、実世界などの汎用表現には適していません。
質問自体に関して：
すべてのデータベース開発者は、「リレーショナル」が「SQL」と等しくないことを知っている必要があります。それから彼らは、DBMSベンダーにどうしてそんなにひどく失望させられているのか、そして彼らが陽気な量を吸い続けたいなら、同じベンダーにもっと良いもの（真にリレーショナルなDBMSなど）を思い付くように言うべき理由を理解するでしょうそのようなくだらないソフトウェアに対する顧客からのお金）。
そして、すべてのデータベース開発者は、リレーショナル代数に関するすべてを知っている必要があります。その後、Stack Overflowでこれらの愚かな「仕事をする方法がわからず、他の誰かが私のためにやりたい」という質問を投稿しなければならない開発者が1人もいなくなりました。
強力な基本的なSQLスキルがあると思います。これまで、データベースについては少し知っているが、非常に単純なクエリを作成する方法についてのヒントを常に求めている多くの開発者を見てきました。クエリは必ずしもそれほど簡単で単純ではありません。適切に正規化されたデータベースを照会する場合、複数の結合（内部、左など）を使用する必要があります。
使用する構文および概念オプション（結合、トリガー、ストアドプロシージャなど）以外に、データベースを使用するすべての開発者にとって重要なことは次のとおりです。
エンジンがどのように具体的に記述しているクエリを実行するかを把握します。
これがとても重要だと思う理由は、単に生産の安定性です。長い関数が完了するのを待っている間、スレッドですべての実行を停止しないようにコードの実行方法を知っておく必要があります。そのため、クエリがデータベース、プログラム、さらにはサーバー？
これは、実際には、セミコロンなどが欠落しているよりも、R＆Dチームを何度も襲ったものです。クエリは、テーブルに数千行しかない開発システムで実行されるため、クエリは迅速に実行されると推定されます。本番データベースが同じサイズである場合でも、使用される可能性が非常に高いため、複数のユーザーが同時にデータベースにアクセスしたり、別のクエリで問題が発生したりするなど、他の制約を受けます。このクエリの結果。
結合がクエリのパフォーマンスにどのように影響するかなどの単純なことでさえ、本番環境では非常に貴重です。概念的に物事を簡単にする多くのデータベースエンジンの多くの機能がありますが、明確に考えないとパフォーマンスに落とし穴が生じる可能性があります。
データベースエンジンの実行プロセスを把握し、計画します。
非正規化 を悪魔ではなく天使として考え、また NoSQLデータベース をリレーショナルデータベースの代替として考えてください。
また、Entity-Relationモデルは、データベースを設計しなくても、すべての開発者が知っておく必要があると思います。データベースの内容を完全に理解できます。
間違ったテキストエンコーディングのデータを挿入しないでください。
データベースが複数のエンコーディングで汚染されると、できることは、ヒューリスティックと手作業の何らかの組み合わせを適用することです。
データベースを頻繁に使用する（毎日またはほぼ毎日クエリを作成/維持する）道のプロの開発者にとって、期待は他のフィールドと同じであると思います：You大学で書きました。
すべてのC++オタクは大学で文字列クラスを書きました。すべてのグラフィックオタクは大学でレイトレーサーを書きました。すべてのWebオタクは、大学でインタラクティブなWebサイトを作成しました（通常、「Webフレームワーク」ができる前）。すべてのハードウェアオタク（およびソフトウェアオタクも）は、大学でCPUを構築しました。たとえ私の血圧を測定して今日は私のコレステロールが高すぎると言っても、すべての医師は大学で死体全体を解剖しました。データベースが異なるのはなぜですか？
残念ながら、今日、何らかの理由で、それらは異なっているように見えます。 .NETプログラマーに Cでの文字列の動作を知っている が、RDBMSの内部 あまり気にする必要はない を求めています。
それらについて読んだり、上から下に向かって作業したりしても、同じレベルの理解を得ることは事実上不可能です。しかし、下から始めて各要素を理解すれば、データベースの詳細を比較的簡単に把握できます。非リレーショナルデータベースを使用する場合のように、多くのデータベースオタクが見苦しそうに見えることさえありません。
特に大学でコンピューターサイエンスを勉強していなかった場合は、少し厳しいかもしれません。少し調子を整えます：今日は完全に書くことができます。 PostgreSQLクエリオプティマイザーの機能の詳細を知っていても構いませんが、自分で作成するのに十分な知識があれば、おそらくそれらが実行した内容とあまり変わらないでしょう。そして、ご存知のように、基本的なものを書くのはそれほど難しくありません。
- 基本的なSQLスキル。
- インデックス作成。
- DATE/TIME/TIMESTAMPのさまざまな化身に対処します。
- JDBCドライバー 使用しているプラットフォームのドキュメント。
- バイナリデータ型を処理する（ [〜＃〜] clob [〜＃〜] 、 [〜＃〜] blob [〜＃〜] など）
一意でないインデックスの列の順序は重要です。
最初の列は、コンテンツの変動性が最も大きい列（つまり、カーディナリティ）でなければなりません。
これは、SQL Serverが実行時にインデックスを使用する方法で有用な統計を作成できるようにするためです。
データベースのプログラミングに使用するツールを理解してください!!!
私のコードが不可解に失敗した理由を理解しようとして、私は多くの時間を無駄にしました。
たとえば、.NETを使用している場合、System.Data.SqlClient名前空間のオブジェクトを適切に使用する方法を知る必要があります。 SqlConnectionオブジェクトを管理する方法を知って、それらが開かれ、閉じられ、必要に応じて適切に破棄されることを確認する必要があります。
SqlDataReaderを使用するときは、SqlConnectionとは別に閉じる必要があることを知っておく必要があります。データベースへのヒット数を最小限に抑える方法に適したときに接続を開いたままにする方法を理解する必要があります（計算時間の点で比較的高価であるため）。
インピーダンス不整合の問題、および一般的な欠陥またはORMを知っています。
3（もの）は魔法の数です：
データベースにもバージョン管理が必要です。
カーソルはslowであり、おそらく必要ありません。
トリガーは悪*
*ほとんどいつも
RDBMS互換性
アプリケーションを複数のRDBMSで実行する必要があるかどうかを確認します。はいの場合、次のことが必要になる場合があります。
- rDBMS SQL拡張機能を避ける
- トリガーを削除してプロシージャを保存する
- 厳格なSQL標準に従う
- フィールドのデータ型を変換する
- トランザクション分離レベルを変更する
それ以外の場合、これらの質問は個別に扱われ、アプリケーションの異なるバージョン（または構成）が開発されます。
一部のプロジェクトでは、オブジェクト指向モデルの方が優れています。
他のプロジェクトでは、リレーショナルモデルの方が優れています。
SQLクエリによって返される行の順序に依存しないでください。