好むと好まざるとにかかわらず、ほとんどの開発者は、データベースを定期的に使用するか、いつかデータベースを使用する必要があるかもしれません。そして、実際の悪用や乱用の量、および毎日出てくるデータベース関連の質問の量を考えると、開発者が設計または操作しなくても、知っておくべき特定の概念があると言っても過言ではありません。今日のデータベース。そう：

開発者や他のソフトウェア専門家がデータベースについて知っておくべき重要な概念は何ですか？

対応のガイドライン：

リストは短くしてください。
回答ごとに1つのコンセプトが最適です。

具体的に。
「データモデリングは、」重要であるかもしれないスキルが、正確にはそれがどういう意味？

根拠を説明してください。
なぜあなたのコンセプトは重要ですか？「インデックスを使う」とだけ言ってはいけません。「ベストプラクティス」に陥らないでください。視聴者を説得してもっと学びましょう。

同意する回答に賛成票を投じます。
最初に他の人の答えを読んでください。ランクの高い回答1つは、ランクの低い回答2つよりも効果的なステートメントです。さらに追加する必要がある場合は、コメントを追加するか、オリジナルを参照してください。

個人的に当てはまらないからといって、反対投票しないでください。
私たちは皆、異なるドメインで働いています。ここでの目的は、データベースの初心者がデータベース設計とデータベース駆動型開発について十分に根拠のある包括的な理解を得るための方向性を提供することです。

開発者がデータベースについて最初に知っておくべきことはこれです：データベースは何ですか？それらがどのように機能するのか、どのように構築するのか、データベースのデータを取得または更新するコードをどのように作成するのかではありません。しかし、それらは何のためのものですか？

残念ながら、これに対する答えは動く目標です。 1970年代から1990年代初頭にかけてのデータベースの全盛期では、データベースはデータを共有するためのものでした。 データベースを使用していて、データを共有していない場合は、学術プロジェクトに参加しているか、自分自身を含むリソースを浪費していました。データベースのセットアップとDBMSの管理は非常に記念碑的な作業であり、データを複数回利用するという点で、投資に見合うだけの投資が必要でした。

過去15年間で、データベースは、1つのアプリケーションに関連付けられた永続データを格納するために使用されるようになりました。MySQL、Access、またはSQL Serverの データベースを構築することは非常に日常的なこととなっており、データベースは通常のアプリケーションのほぼ日常的な部分になっています。データの実際の値が明らかになると、最初の限定されたミッションがミッションクリープによって押し上げられることがあります。残念ながら、単一の目的を念頭に置いて設計されたデータベースは、企業全体のミッションクリティカルな役割に移行し始めると、劇的に機能しなくなることがよくあります。

開発者がデータベースについて学ぶ必要がある2番目のことは、世界全体のデータ中心のビューです。データ中心の世界観は、プロセス中心の世界観とは、ほとんどの開発者がこれまでに学んだことのどれよりも異なります。このギャップと比較して、構造化プログラミングとオブジェクト指向プログラミングの間のギャップは比較的小さいです。

開発者が少なくとも概要で学ぶ必要がある3番目の事項は、概念データモデリング、論理データモデリング、物理データモデリングなどのデータモデリングです。

概念的なデータモデリングは、データ中心の観点からの要件分析です。

論理データモデリングは、通常、概念的なデータモデリングで発見された要件に特定のデータモデルを適用したものです。リレーショナルモデルは他の特定のモデルよりもはるかに多く使用されており、開発者はリレーショナルモデルを確実に学習する必要があります。重要な要件に対して強力で関連性のあるリレーショナルモデルを設計することは、重要な作業ではありません。リレーショナルモデルを誤解していると、適切なSQLテーブルを作成できません。

物理データモデリングは一般にDBMS固有であり、開発者がデータベースビルダーまたはDBAでもない限り、詳細に学習する必要はありません。開発者が理解する必要があるのは、物理データベースの設計を論理データベースの設計から分離できる範囲と、物理データベースの設計を調整するだけで高速データベースを作成できる範囲です。

開発者が次に学ばなければならないことは、速度（パフォーマンス）は重要ですが、データベースの範囲を修正して拡張する機能やプログラミングの単純さなど、設計の良さの他の測定基準がさらに重要であることです。

最後に、データベースをいじる人は誰でも、データの価値がそれを取り込んだシステムよりも長持ちすることを理解する必要があります。

ふew！

良い質問。以下は、順不同のいくつかの考えです。

1. 少なくとも第2正規形への正規化は不可欠です。

2. 参照整合性も不可欠であり、適切なカスケード削除と更新を考慮します。

3. チェック制約の適切で適切な使用。データベースにできるだけ多くの処理を行わせます。

4. データベースと中間層コードの両方にビジネスロジックを分散させないでください。どちらか一方、できれば中間層のコードを選択します。

5. 主キーとクラスター化キーの一貫したアプローチを決定します。

6. インデックスを付けすぎないでください。インデックスは賢く選択してください。

7. 一貫したテーブルと列の命名。標準を選択し、それに固執します。

8. NULL値を受け入れるデータベースの列数を制限します。

9. トリガーに夢中にならないでください。それらには用途がありますが、急いで物事を複雑にする可能性があります。

10. UDFには注意してください。それらはすばらしいですが、クエリで呼び出される頻度を知らない場合は、パフォーマンスの問題を引き起こす可能性があります。

11. データベース設計に関するCelkoの本を入手してください。その男は傲慢ですが、彼のものを知っています。

まず、開発者はデータベースについて知っておくべきことがあるということを理解する必要があります。それらは、SQLを挿入して結果セットを取得する魔法のデバイスではなく、独自のロジックと癖を持つ非常に複雑なソフトウェアです。

第2に、目的ごとに異なるデータベース設定があることです。利用可能なデータウェアハウスがある場合、開発者がオンライントランザクションデータベースから履歴レポートを作成することは望ましくありません。

3番目に、開発者は結合を含む基本的なSQLを理解する必要があります。

これを過ぎると、それは開発者がどれだけ密接に関与しているかに依存します。私は、私が開発者であり事実上DBAであり、DBAが通路のすぐ下にいて、DBAが自分の領域にいない場所で働いていました。（私は3番目が嫌いです。）開発者がデータベース設計に関与していると仮定します。

彼らは基本的な正規化、少なくとも最初の3つの正規形を理解する必要があります。それ以上のものは、DBAに連絡してください。米国の法廷での経験（およびランダムなテレビ番組の数はここでカウントされます）のある人には、「キー、キー全体、そしてキーだけに依存するので、コッドを助けてください」というニーモニックがあります。

インデックスについての手がかりが必要です。つまり、必要なインデックスと、パフォーマンスにどのような影響を与える可能性があるかについて、ある程度の知識が必要です。これは、無駄なインデックスがないことを意味しますが、クエリを支援するためにそれらを追加することを恐れません。それ以上のもの（残高など）はDBAに残してください。

彼らはデータの整合性の必要性を理解し、データを検証している場所と、問題が見つかった場合に何をしているのかを指摘できる必要があります。これはデータベース内にある必要はありません（ユーザーにとって意味のあるエラーメッセージを発行することが困難な場合）が、どこかにある必要があります。

彼らは、計画を取得する方法、および一般にそれを読む方法の基本的な知識を持っている必要があります（少なくともアルゴリズムが効率的であるかどうかを判断するには十分です）。

彼らはトリガーとは何か、ビューとは何か、データベースの断片を分割することが可能であることを漠然と知っているはずです。詳細は必要ありませんが、DBAにこれらのことについて尋ねる必要があります。

もちろん、プロダクションデータやプロダクションコードなどをいじらないことを知っている必要があり、すべてのソースコードがVCSに入ることを知っている必要があります。

私は間違いなく何かを忘れましたが、実際のDBAが手元にあれば、平均的な開発者はDBAである必要はありません。

基本的なインデックス作成

インデックスのないテーブルやデータベース全体、または任意の/役に立たないインデックスを見ると、いつもショックを受けます。データベースを設計しておらず、いくつかのクエリを記述する必要がある場合でも、少なくとも理解することが重要です。

• データベースでインデックス付けされるものとそうでないもの：
• スキャンの種類の違い、スキャンの選択方法、およびクエリの記述方法がその選択にどのように影響するか。
• カバレッジの概念（なぜ書くだけではいけないのかSELECT *）;
• クラスター化インデックスと非クラスター化インデックスの違い。
• インデックスの数が多い/大きいほど、必ずしも良いとは限らないのはなぜですか。
• 関数でフィルター列をラップしないようにする必要がある理由。

設計者は、たとえば次のような一般的なインデックスのアンチパターンにも注意する必要があります。

• Accessアンチパターン（すべての列に1つずつインデックスを付ける）
• キャッチオールアンチパターン（すべてまたはほとんどの列に1つの大きなインデックスがあり、これらの列のいずれかを含む考えられるすべてのクエリが高速化されるという誤った印象の下で作成されたようです）。

データベースのインデックスの品質-あなたはあなたが書いたクエリでそれを活用するかどうか-のアカウントはるかにパフォーマンスの最も重要な塊。パフォーマンスの低下について不平を言っているSOおよび他のフォーラムに投稿された10問中9問は、常に、インデックス付けが不十分であるか、引数をとらない式が原因であることが判明します。

正規化

正規化されたデザイン（「地域ごとの総売上高を表示してください。」）で完全に単純なものになり過ぎる、非常に複雑なクエリを書くのに苦労している人を見ると、いつもがっかりします。

これを最初に理解し、それに応じて設計すれば、後で多くの苦痛を省くことができます。正規化した後でパフォーマンスを非正規化するのは簡単です。最初からそのように設計されていないデータベースを正規化することはそれほど簡単ではありません。

少なくとも、3NFとは何か、そしてそこに到達する方法を知っている必要があります。ほとんどのトランザクションデータベースでは、これはクエリを簡単に記述できるようにすることと、良好なパフォーマンスを維持することとの非常に良いバランスです。

インデックスのしくみ

それはおそらく最も重要ではないでしょうが、確かに最も過小評価されているトピックです。

索引付けの問題は、SQLチュートリアルでは通常それらについてまったく言及されておらず、すべてのおもちゃの例が索引なしで機能することです。

さらに熟練した開発者であれば、「インデックスはクエリを高速化する」よりもインデックスについての知識がなくても、かなり良い（そして複雑な）SQLを書くことができます。

これは、SQLデータベースがブラックボックスとして非常に優れた機能を果たすためです。

必要なものを教えてください（gimme SQL）、私が担当します。

そして、それは完全に機能し、正しい結果を取得します。SQLの作成者は、システムが舞台裏で何をしているのかを知る必要はありません。

インデックスがトピックになるときです。しかし、それは通常非常に遅く、誰か（会社によっては？）はすでに本当の問題に苦しんでいます。

そのため、データベースを操作するときに忘れないでください。残念ながら、忘れがちです。

免責事項

議論は私の無料の電子ブック「Use The Index、Luke」の序文から借用したものです。インデックスがどのように機能し、適切に使用する方法を説明するのにかなりの時間を費やしています。

私は観察結果を指摘したいだけです-つまり、応答の大部分はデータベースがリレーショナルデータベースと交換可能であると想定しているようです。オブジェクトデータベース、フラットファイルデータベースもあります。手元にあるソフトウェアプロジェクトのニーズを評価することが重要です。プログラマーの観点からは、データベースの決定を後で延期することができます。一方、データモデリングは早い段階で達成でき、多くの成功につながります。

データモデリングは重要なコンポーネントであり、比較的古い概念ですが、ソフトウェア業界では多くの人が忘れていた概念です。データモデリング、特に概念モデリングは、システムの機能的な動作を明らかにし、開発のロードマップとして信頼できます。

一方、必要なデータベースのタイプは、環境、ユーザーボリューム、ハードドライブ領域などの使用可能なローカルハードウェアなど、さまざまな要因に基づいて決定できます。

SQL インジェクションの回避とデータベースの保護方法

「データベース操作のプロファイリングは、コードのプロファイリングとはまったく異なります。」

従来の意味での明確なBig-Oがあります。あなたが行うとEXPLAIN PLAN（または同等の）あなたは、アルゴリズムを見ています。一部のアルゴリズムはネストされたループを含み、O（n ^ 2）です。他のアルゴリズムはBツリールックアップを含み、O（n log n）です。

これは非常に深刻です。インデックスが重要である理由を理解することが中心です。これは、速度の正規化と非正規化のトレードオフを理解するための中心です。データウェアハウスが、トランザクションの更新に対して正規化されていないスタースキーマを使用する理由を理解するための中心です。

使用されているアルゴリズムが不明な場合は、以下を実行してください。やめる。クエリ実行プランについて説明します。それに応じてインデックスを調整します。

また、当然のことですが、インデックスが多いほど良くはありません。

ある操作に焦点を当てたインデックスが他の操作の速度を低下させることがあります。2つの操作の比率によっては、インデックスを追加しても効果があり、全体的な影響がないか、全体的なパフォーマンスに悪影響を与える可能性があります。

すべての開発者は、データベースには異なるパラダイムが必要であることを理解する必要があると思います。

データを取得するクエリを作成するときは、セットベースのアプローチが必要です。インタラクティブな背景を持つ多くの人々はこれに苦労しています。それでも、彼らがそれを採用するとき、解決策は繰り返しに焦点を当てた頭の中で最初に現れたものではないかもしれませんが、はるかに優れた結果を達成できます。

すばらしい質問です。まず、結合を完全に理解していないデータベースにクエリを実行することを検討する必要はありません。それは、ハンドルとブレーキがどこにあるかを知らずに車を運転するようなものです。また、データ型と、最適なデータ型を選択する方法も知っておく必要があります。

開発者が理解する必要があるもう1つのことは、データベースを設計する際に3つの点に留意する必要があることです。

1. データの整合性-データが信頼できない場合、基本的にデータがありません。これは、他の多くのソースがデータベースにアクセスする可能性があるため、アプリケーションに必要なロジックを配置しないことを意味します。データの整合性を保つには、制約、外部キー、および場合によってはトリガーが必要です。あなたがそれらを好きではない、またはそれらを理解するために煩わされたくないので、それらを使用することを忘れないでください。

2. パフォーマンス-パフォーマンスの低いデータベースをリファクタリングすることは非常に難しく、パフォーマンスは最初から検討する必要があります。同じクエリを実行するには多くの方法があり、いくつかはほとんど常に高速であることが知られています。これらの方法を学習して使用しないことは近視眼的です。クエリやデータベース構造を設計する前に、パフォーマンスチューニングに関する本を読んでください。

3. セキュリティ-このデータは会社の生命線であり、盗まれることのある個人情報も含まれていることがよくあります。SQLインジェクション攻撃、詐欺、ID盗難からデータを保護する方法を学びます。

データベースにクエリを実行すると、間違った答えが返されやすくなります。データモデルを完全に理解していることを確認してください。多くの場合、実際の決定はクエリが返すデータに基づいて行われます。それが間違っていると、間違ったビジネス上の決定が行われます。あなたは悪いクエリから会社を殺したり、大きな顧客を失ったりすることができます。データには意味があり、開発者はしばしばそれを忘れているようです。

データが消えることはほとんどありません。今日のデータを取得する方法ではなく、長期にわたってデータを保存することを考えてください。10万件のレコードがあったときに正常に機能したデータベースは、10年間ではそれほど良くないかもしれません。アプリケーションがデータの期間だけ続くことはめったにありません。これが、パフォーマンスの設計が重要である理由の1つです。

データベースには、アプリケーションが見る必要のないフィールドがおそらく必要です。レプリケーションのGUID、日付挿入フィールドなど。また、変更の履歴と、誰がいつ変更したかを保存し、この保管庫から悪い変更を復元できるようにする必要がある場合もあります。更新にwhere句を指定するのを忘れてテーブル全体を更新した問題を修正する方法をWebサイトに尋ねる前に、これをどのように行うつもりかを考えてください。

本番バージョンよりも新しいバージョンのデータベースで開発しないでください。本番データベースに対して直接開発することは決してありません。

データベース管理者がいない場合は、誰かがバックアップを作成し、それらを復元する方法を知っていること、およびそれらの復元をテストしたことを確認してください。

データベースコードはコードであり、他のコードと同じようにソース管理に保持しないことの言い訳はありません。

進化的データベース設計。http://martinfowler.com/articles/evodb.html

これらのアジャイル手法により、データベース変更プロセスが管理可能、予測可能、およびテスト可能になります。

開発者は、バージョン管理、継続的な統合、および自動テストの観点から、本番データベースをリファクタリングするために必要なことを知っておく必要があります。

進化的なデータベース設計プロセスには管理上の側面があります。たとえば、このコードベースのすべてのデータベースで、ある期間が経過すると列が削除されます。

少なくとも、データベースのリファクタリングの概念と方法論が存在することは知っています。 http://www.agiledata.org/essays/databaseRefactoringCatalog.html

分類とプロセスの説明により、これらのリファクタリングのためのツールを実装することも可能になります。

リレーショナルデータベースの私の経験から、すべての開発者は知っておくべきです：

-さまざまなデータ型：

正しいジョブに正しいタイプを使用すると、DB設計がより堅牢になり、クエリが高速になり、作業が楽になります。

-1xMとMxMについて学ぶ：

これは、リレーショナルデータベースの基本です。1対多および多対多の関係を理解し​​、必要に応じて適用する必要があります。

-「KISS」の原則はDBにも適用されます。

シンプルさが常に最適です。DBがどのように機能するかを調査していれば、メンテナンスと速度の問題につながる不必要な複雑さを回避できます。

-インデックス：

それらが何であるかを知っていれば十分ではありません。それらをいつ使用するか、いつ使用しないかを理解する必要があります。

また：

• ブール代数はあなたの友達です
• 画像：DBに保存しないでください。理由は聞かないでください。
• SELECTでDELETEをテストする

ビジネスドメインを適切にモデル化する方法、およびそのビジネスドメインモデルを正規化されたデータベースの論理モデル、最適化された物理モデル、および適切なオブジェクト指向クラスモデル。それぞれがさまざまな理由で異なる（ある可能性があります）ので、いつ、なぜ、どのように異なる（または異なる必要がある）かを理解します。

強力な基本的なSQLスキルと言えます。これまで、データベースについては少し知っているが、非常に単純なクエリを作成する方法についてのヒントを常に求めている多くの開発者を見てきました。クエリは必ずしもそれほど簡単で単純なわけではありません。適切に正規化されたデータベースをクエリする場合、複数の結合（内部、左など）を使用する必要があります。

Walter M.の回答に対する次のコメントについて：

「非常によく書かれている！そして、歴史的展望は、当時データベース作業をしていない人々（すなわち、私）にとって素晴らしい。」

歴史的展望はある意味で絶対的に重要です。「歴史を忘れた人は、それを繰り返す運命にある。」Cfr XMLは過去の階層の間違いを繰り返し、グラフデータベースは過去のネットワークの間違いを繰り返し、OOシステムは階層モデルをユーザーに強制しますが、脳の10分の1でも誰でも階層モデルは一般に適していないことを知っているはずです。現実世界などの目的の表現。

質問自体に関しては：

すべてのデータベース開発者は、「リレーショナル」が「SQL」に等しくないことを知っている必要があります。次に、DBMSベンダーによって非常に落胆している理由と、陽気な量を吸うことを希望する場合に、同じベンダーにもっと良いもの（たとえば、真に関係のあるDBMS）を考え出すように指示する必要がある理由を理解します。そのような安っぽいソフトウェアのために顧客からのお金）。

そして、すべてのデータベース開発者は、リレーショナル代数についてのすべてを知っている必要があります。そうすれば、スタックオーバーフローに関するこれらの愚かな「自分の仕事のやり方がわからないので、誰かにやらせてほしい」という質問を投稿しなければならない開発者が1人もいなくなります。

ここでは技術的な詳細の多くがカバーされていると思いますが、それらに追加したくありません。私が言いたいことの1つは、技術的というより社会的なことです。アプリケーション開発者としての「DBAは最良を知っている」という罠に陥らないでください。

クエリでパフォーマンスの問題が発生している場合は、問題の所有権も取得してください。独自の調査を行い、何が起こっているのか、そしてその解決策が問題にどのように対処しているかをDBAに説明してもらいます。

調査が終わったら、自分の提案も考えてください。つまり、データベースの問題をDBAに任せるのではなく、問題の協調的な解決策を見つけようとします。

単純な敬意。

• それは単なるリポジトリではありません
• あなたはおそらくベンダーやDBAよりもよく知らないでしょう
• 上級管理者があなたに向かって叫んでいるため、午前3時はサポートしません。

非正規化は悪魔ではなく天使の可能性があると考えてください。また、NoSQLデータベースも考慮してください。。また、リレーショナルデータベースの代わりにをください。

また、Entity-Relationモデルは、データベースを設計していなくても、すべての開発者にとって知っておくべきことだと思います。それはあなたがあなたのデータベースが何であるかを徹底的に理解させるでしょう。

間違ったテキストエンコーディングでデータを挿入しないでください。

データベースが複数のエンコーディングで汚染されたら、最善の方法は、ヒューリスティックと手作業の何らかの組み合わせを適用することです。

使用する構文と概念のオプション（結合、トリガー、ストアドプロシージャなど）以外に、データベースを使用するすべての開発者にとって重要なことの1つは次のとおりです。

エンジンが具体的に記述しているクエリを実行する方法を把握します。

これが非常に重要だと思う理由は、単に生産の安定性です。長い関数が完了するのを待つ間、スレッド内のすべての実行を停止しないように、コードがどのように実行されるかを知っておく必要があります。それで、クエリがデータベース、プログラム、そしておそらくサーバー？

これは実際には、セミコロンなどがない場合よりも、R＆Dチームを襲ったものです。テーブルに数千行しかない開発システムで実行されるため、クエリは迅速に実行されると推定されます。本番データベースが同じサイズであっても、使用頻度が高くなる可能性が高いため、複数のユーザーが同時にデータベースにアクセスしたり、他の場所で別のクエリに問題が発生したりして遅延が発生するこのクエリの結果。

結合がクエリのパフォーマンスにどのように影響するかなどの単純なものでさえ、本番環境では非常に貴重です。多くのデータベースエンジンには、概念的に物事を容易にする多くの機能がありますが、明確に考えなければ、パフォーマンスに問題が生じる可能性があります。

データベースエンジンの実行プロセスを把握し、計画を立てます。

データベースを頻繁に使用する中程度の道のプロの開発者（クエリを毎日またはほぼ毎日作成または保守する）の場合、期待は他の分野と同じであると思います。大学で書いたものです。です。

すべてのC ++オタクは、大学で文字列クラスを書きました。すべてのグラフィックマニアは、大学でレイトレーサーを作成しました。すべてのWebオタクは、大学でインタラクティブなWebサイトを作成しました（通常、 "Webフレームワーク"を導入する前）。すべてのハードウェアオタク（およびソフトウェアオタク）も大学でCPUを構築しました。たとえ彼女が私の血圧を取るだけで今日の私のコレステロールが高すぎると私に言っているとしても、すべての医師は大学で死体全体を解剖しました。データベースが異なるのはなぜですか？

残念ながら、それらは今日、何らかの理由で異なっているように見えます。人々は.NETプログラマーにCで文字列がどのように機能するかを知りたいと思っていますが、RDBMSの内部はあまり気にする必要はありません。

それらについて読んだり、上から下に向かって作業したりするだけで同じレベルの理解を得るのは事実上不可能です。しかし、一番下から始めて各部分を理解すれば、データベースの詳細を理解するのは比較的簡単です。非リレーショナルデータベースをいつ使用するかなど、多くのデータベースオタクがひどいことをすることはできません。

特に大学でコンピュータサイエンスを勉強していなかった場合は、少し厳しいかもしれません。私はそれをいくつかトーンダウンします：あなたは今日、完全にゼロからそれを書くことができます。PostgreSQLクエリオプティマイザがどのように機能するかの詳細を知っていてもかまいませんが、自分で作成するのに十分な知識があれば、おそらくそれらが行ったものとそれほど変わりません。基本的なものを書くのはそれほど難しくありません。

一意でないインデックスの列の順序は重要です。

最初の列は、その内容（すなわち、カーディナリティー）の変動が最も大きい列でなければなりません。

これは、SQL Serverが実行時にインデックスを使用する方法に関する有用な統計を作成する機能を支援するためです。

データベースのプログラミングに使用するツールを理解してください!!!

私のコードがなぜ不可解に失敗するのかを理解しようとするのに多くの時間を費やしました。

たとえば、.NETを使用している場合、System.Data.SqlClient名前空間でオブジェクトを適切に使用する方法を知る必要があります。SqlConnectionオブジェクトを管理して、オブジェクトを開いたり、閉じたり、必要に応じて適切に破棄したりする方法を知る必要があります。

を使用する場合はSqlDataReader、とは別に閉じる必要があることを知っておく必要がありますSqlConnection。データベースへのヒットの数を最小限に抑える方法が適切な場合は、接続を開いたままにする方法を理解する必要があります（計算時間の点で比較的コストがかかるため）。

• 基本的なSQLスキル。
• 索引付け。
• DATE / TIME / TIMESTAMPのさまざまな化身に対処します。
• JDBCドライバー使用しているプラ​​ットフォームのドキュメント。
• バイナリデータ型（CLOB、BLOBなど）を処理する

一部のプロジェクトでは、オブジェクト指向モデルの方が適しています。

他のプロジェクトでは、リレーショナルモデルの方が適しています。

インピーダンス不整合の問題であり、一般的な欠陥またはORMを知っています。

RDBMSの互換性

アプリケーションを複数のRDBMSで実行する必要があるかどうかを確認します。はいの場合、次のことが必要になる場合があります。

• RDBMS SQL拡張を避ける
• トリガーとストアプロシージャを排除
• 厳格なSQL標準に従う
• フィールドのデータ型を変換する
• トランザクション分離レベルを変更する

そうでない場合は、これらの質問を個別に扱い、アプリケーションの異なるバージョン（または構成）を開発する必要があります。

SQLクエリによって返される行の順序に依存しないでください。

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/