15

私はデータベース設計と、データを意味的に管理するという概念全体とそれに付随するすべてのロジックを本当に楽しんでいます。

ただし、データベースに関する私の知識レベルは（おそらく）非常に基本的です。ER図、接続テーブル、多対多、1対多などの処理を使用して、データ関係を正しくモデル化できます。経験豊富です。プログラミング全般に関して言えば、私のデータベースの知識は、オブジェクト指向プログラミングの基本、つまり、車のクラスをモデル化する方法、車のクラスから継承する方法、ホイールオブジェクトを含む方法などを知っているようなものだと思います。

ここで、リレーショナルデータベースについての知識を深め、専門家レベルでこのテーマを処理できることを雇用主に自信を持って伝えたいと思います。

私が今扱えるのは、おそらく私の個人Webサイトのバックエンドにある私の映画データベースだけです。これは、私がAmazonで、何百万もの映画を保存しなければならなかった場合、おそらく崩壊するでしょう。では、スケーラビリティの問題はありますか？データベース設計には、専門家レベルでデータベースを操作する場合に理解し、実際に適用できる必要がある、かなり「標準的な」一連の主題/概念があると確信しています。

ですから、この分野のデータベースの達人が、データベースを本当に上手くするために研究するのに有益ないくつかの分野、概念、ケーススタディ、または何かに名前を付けることができれば、私は非常にありがたいです。ここには膨大な科学が潜んでいると確信しており、私はそれを望んでいます。

前もって感謝します！

4

19 に答える 19

9

この分野の標準テキストは、CJ Date による「データベース システムの紹介」です。

私は 20 年の C 経験があります。私はそれを読み、素晴らしいと思い、そのためにリレーショナル データベースを作成しました (この SQL の悪意ではなく、適切なデータベースです!)。

于 2009-04-15T11:26:22.547 に答える
3

CJ Date のDatabase In Depth: Relational Theory for Practitionersからさらに情報を入手してください。

真剣に、これらの 2 冊の本は、他の多くのプロのデータベース作業者が所有しているよりもはるかに少ないスペースで、RDBMS に関する非常に多くの知識を提供します。特に、Database in Depth では、言語がそれをサポートしていない場合でもデータベースをリレーショナルに考える方法と、SQL をだましてリレーショナル言語に近づける方法に注目しています。

于 2009-04-27T08:11:45.207 に答える
3

データベースを使ったプログラミングの側面として考慮すべき分野のリストをボランティアとして提供します。DBMS を使用してプログラミングするために、あるいは DBMS をプログラミングするためにさえ、それらのすべて、またはほとんどの専門家である必要があるとは言いません。ただし、これらはすべて、場合によっては何らかの関連性があるトピックです (順不同)。

  • クエリ言語の設計
  • クエリの最適化
  • クエリの書き換え
  • データ型
  • 保管組織
  • 取引管理
  • 通信プロトコル
  • 暗号化
  • 認証と識別
  • スキーマ設計
  • レプリケーション
  • バックアップと復元
  • 2 フェーズ コミット
  • オプティミスティック同時実行制御
  • ロックと悲観的同時実行制御
  • 認可
  • ラベルベースのアクセス制御
  • 集合論
  • リレーショナル理論
  • 分散クエリ
  • ブール論理
  • ユーザー定義の型と関数
  • カタログ管理
  • バッファ管理
  • 並べ替え
  • 国際化 (I18N)、ローカリゼーション (L10N)、グローバリゼーション (G11N)
  • 数量詞
  • 監査
  • トリガー
  • ストアド プロシージャ

完全性や最小性についても主張しません。

于 2009-04-28T03:25:26.027 に答える
2

集合 + 関係代数は、ほとんどのデータベース ユーザーがほとんど知らないことだと思いますが、学ぶのはよいことです。1 つのリレーションを別のリレーションにマッピングする背後にあるロジックを理解すると、正規化などの機能が優れている理由、可能であれば NULL を避けるのが最善である理由などをより明確に理解できるようになります。また、より純粋なリレーショナル クエリ言語と比較した SQL の欠点にも気付き始めます。 、機能がパフォーマンス上の理由などによりパラダイムに制限を課す場合。

于 2009-04-28T23:50:05.787 に答える
2

データベースの学生なので、限られた範囲からしか話すことができませんが、役立つ可能性のある2つのサイトを提案できます...

http://database-programmer.blogspot.com/2008/09/comprehensive-table-of-contents.html

これは Kenneth Downs のサイトです。彼は SQL の基本から始めて、より複雑なテーマを掘り下げています。結局、男は DB の周りのフレームワークを書きました。

もう1つは高いスケーラビリティです...

http://highscalability.com/

彼らはDBのあらゆる領域に入ります。

お役に立てれば。

于 2009-04-28T05:12:28.640 に答える
1

これは、データベースで何をしたいか、データがどのように見えるか、ワークフローは何か、サーバー、クライアント、データベースの数によって異なります...

ですから、私のように、大きくない（それぞれ100 GB未満）複数のデータベースを処理する必要があり、カスタムレポートの作成やエクスポートなど、さまざまなニーズを持つ多くのクライアントがいて、多くのカスタムソリューションを開発しているとしましょう。これにより、DBAというよりもプログラマーになります。そして、必要なのはパフォーマンスよりも生産性です。

そのような状況で私が思いついた最善の解決策は、SQLを可能な限り取り除くことです。これは、自家製または既存のORMを使用して、SQLスクリプトをオブジェクトプログラミングと交換することで実現できます。これを行うと、SQLでは数時間かかることを数分で実行できます。

于 2009-04-28T16:09:16.907 に答える
1

まあ、それは常に良い設計例です...何かのためにデータベースが必要な人を知っているかどうかを確認してください。しかし、関心のある業界によっては、VLDB (Very Large DataBase) 手法を学ぶことが役立つ場合があります。

于 2009-04-15T11:26:24.993 に答える
1

免責事項: データベース設計の専門家ではありません。

パフォーマンスの問題の一部は、次のいずれかで処理できます。

  1. データベースを非正規化し、結合するテーブルの数を減らす
  2. 索引の追加
  3. 最初に一致しないデータの最大のものを削除してから、削減されたセットで次の条件を選択するように、フィルタリングを行う必要があります。100 個の値 -> 最初の条件に一致する 10 個 -> 最初と 2 番目の条件に一致する 1 個の値 -> 2 番目の条件に一致する 80 個の値 -> 最初と 2 番目の条件に一致する 1 個よりも良いです。些細なことのようですが、心に留めておくことが重要です。

  4. 分断 と 支配がスケーラビリティのモットーです。O(N^2) など、非線形にスケーリングするものがある場合は、N をできるだけ低く保つことが理にかなっており、データセットを小さなセットに分割する必要があります。パーティショニングを実行します。この例はシャーディングで、通常は大規模なソーシャル Web サイトでユーザーのデータベースを保持するために使用されます。（注：例として、私はこのように実装しません）すべてのユーザーを含む巨大なデータベースを用意する代わりに、26台のサーバー（アルファベットの各文字に1台）を用意し、すべてのニックネームを同じ最初の文字で配置します同じサーバーで。これには次の利点があります。

    a.
    a.異なるマシンで負荷を分散します。1 台のマシンがクラッシュした場合、すべてのユーザーではなく、一部のユーザーのみがサイトにアクセスできないようにします
    c. 高度な識別基準 (最初の文字) で検索を事前に選択してから、2 番目の検索 (ユーザー名) を実行します
    。各データベースのエントリ数を減らします。

于 2009-04-29T00:13:35.400 に答える
1

私の考えでは、データベース スキルには、開発者、DBA、アーキテクトの 3 つの「トラック」があります。開発の観点からは、開発に集中し、Architect を理解し、途中で必要なだけ DBA の知識を習得します。

開発者として (私の考えでは) 重要なことは、SQL を本当に優れた標準にすることです。私が開発者を探している場合のインタビュアーとして、データベースを設計できるかどうかは気にしません。基本的な CRUD コマンドについて知っていると仮定すると、次のことについて知っていますか?

ストアド プロシージャ (使用方法だけでなく、いつ、どのような理由で)
ビュー (マテリアライズド ビューを含む)
トリガー (挿入、更新、削除、方法と理由)
カーソル (特にパフォーマンスへの影響)
参照整合性
トランザクション
インデックス
デフォルト、制約、および追加テーブルへのアイデンティティ
group by と have
関数の複雑な使用 特に:
- 日付と時刻の操作
- 文字列の操作
- null の処理

SQL のみを使用してデータベースから必要なデータを取得できる必要があります。手続き型コードを使用して、何らかの方法でデータを操作または解析する必要はありません (選択することもできますが、そうしなかったのではなく選択することになります)。 SQLでそれを行う方法を知っています）。

開発者として私が注目したいのは、Joe Celko の SQL for Smarties です。SQL で実行できるとは考えもしなかったようなことを実行できる SQL がたくさんあります。

このことを学ぶための最良の方法の 1 つは、退屈そうに見えますが、レポート (経営情報) を書くことです。私は非常に多くの人がレポートを書くのが面倒だと不満を漏らし、それを本当に、本当にひどいやり方でやっているのを見てきました (そして、彼らが試みなかったという理由だけではありません)。レポートは純粋な SQL に近い傾向があるため、手元にあるツールについてよく理解する必要があり、複雑なレポートでは、SQL を知っている人とそうでない人が明らかになります。また、人々はあまり長く待ちたくない傾向があるため、パフォーマンスも重要です。

現在のデータベースを見て、誰かが実際に知りたがっているかもしれない本当に厄介なことをたくさん考え出してください。マーケティング、トレンド、最も人気のあるものと最も人気のないものを考えてみてください。次に、それらの束を 1 つのクエリに結合してみます。

パフォーマンスに関しては、クエリオプティマイザーがどのように機能するか、いつインデックスを使用するか、いつテーブルスキャンを行うか、インデックスがいつ役に立ち、いつ邪魔になるかを決定する方法についても調べたいと思います。

優れた開発者は、優れたクエリを作成するだけでなく、すばやく保守可能なクエリを作成します。これを実際に理解するには、理想的には数百万行を含む 12 個 (またはそれ以上) のテーブルを持つデータベースをいじる必要があります。それは、かかとを引きずっても問題ないと思っていたクエリが表示されるようになるときです。

他の人がかなりうまくカバーしている建築家/デザイナーのもの。この件に関して私が言いたいのは、設計する必要があるすべてのデータベースに対して、そのデータベース用に作成する必要があるクエリが何百もあるということだけです。スキルを向上させているときは、作業の比例的な内訳を考慮し、クエリが本当にゼロになっていることを確認することをお勧めします。

リンクに関しては、プラットフォームに依存します。これらはすべて、プラットフォーム固有のものになる傾向があります。しかし、それがグーグルの目的です。

私はあなたが何を望んでいるかを完全に疑っていませんが、SQLを知っていると思っている多くの人が本当に知らないので知っておく価値があります...

于 2009-04-29T20:38:09.543 に答える
1

非常に一般的なシナリオは、醜いデータベースを、DB の構造に直接反映される必要のないエンティティ モデルにマップする必要があることです。ドメイン内のデータをモデル化するのに最適な方法を見つけるのは難しい場合があります。

全文検索と XML は、ますます話題になりつつあるテーマです。

私はそれを経験したことはありませんが、DB2 (試用版がある) にはクレイジーな新機能がいくつかあることは知っています)

楽しむ ：-）

于 2009-04-24T08:04:25.547 に答える
1

データベースで階層やグラフを表現することを忘れないでください。それは苦痛であり、正しい答えはありません。

標準的な手法 (少なくとも階層用) は、これらの SO 投稿で言及されています。

編集: GIS 用の空間データベースアプリケーションもあり、 R ツリーなどを使用してポイントの位置に基づいてデータ構造やインデックスを作成します。これらの使用は、通常の非空間データベース機能とは少し異なります。

于 2009-04-29T00:36:07.267 に答える
0

私が知っているリレーショナル データベース スキーマを概念的にモデル化するための厳密な手法は 1 つしかありません (そして、私は多くの時間を費やして調べてきました)。これは紛らわしい「オブジェクト ロール モデリング」という名前です。ここにいくつかの参照があります。

http://www.agilemodeling.com/artifacts/ormDiagram.htm

http://www.tdan.com/view-articles/5033

http://en.wikipedia.org/wiki/Object_role_modeling

http://en.wikipedia.org/wiki/NORMA

ここにVisual Studio用のプラグインがあります

于 2009-04-29T00:24:45.407 に答える
0

率直に言って、データベースはデータを保存してアクセスする方法にすぎません。ファイルシステムもほとんど同じです。

LDAP と同様に、これはプロトコルであり、これによって何ができるか、どのように実装する必要があるかの定義ではありません。SQL についても同じことが言えます。

つまり、データベースについてもっと知りたいということは、実際には、SQL プロトコルやデータの保存方法やフェッチ方法についてもっと知りたいと言っているということです。

「B-Tree」とは何か、またどのように使用されるのかを調べてみたいと思われるかもしれません。調べる価値のあるもう 1 つのことは、EAV (Entity-Attribute-Value) と、スキーマが EAV にとって非常に重要である理由です。

その知識があれば、実際に独自の DB をロールアウトすることができ、それを実行しながら、RDBM が既に行っていることを理解することができます。

より実用的なアプローチが必要な場合は、オープン ソースの PostgreSQL が提供するドキュメントを参照してください。

于 2009-04-30T12:41:09.947 に答える
0

www.dbdebunk.comから始めることを強くお勧めします。理論とは裏腹に実践的な内容が盛りだくさんです。このサイトは少し古いですが、それでも役に立ちます。データベースの専門家になりたいのであれば、商用コンテンツでもそれほど高価ではありません。

于 2009-04-27T18:31:51.113 に答える
0

データベースの基礎と傾向に焦点を当てた (ほぼ最近の) 総説論文の 1 つを読むことから始めることができます: データベース の解剖学

于 2009-05-05T05:46:50.837 に答える