タグ付けされた質問 「database-development」

3
ORMはデータベースの非正規化を促進しますか?
DoctrineとPropelは両方とも単一および具体的なテーブル継承を利用してオブジェクトの関係をマップします。前者は単一のテーブルにマッピングされたクラスツリー内のすべての可能なフィールドを参照しますが、後者は各クラスを特定のテーブルにマッピングし、継承階層の共通フィールドを複製します。 これによりORM装置が容易になりますが、データベース設計が悪いことを示唆しています。これらの悪い設計パターンは、データベースに適用されますか?

3
.NETデータ層を構築するためのMicrosoftの現在のベストプラクティスは?そして現実?
私が作業している開発チームはすぐに.NET 4.0に移行しますが、使用するデータアクセスクラスライブラリは、引き続きADO.NETの「クラシック」、つまりSqlDataReader、DataTableなどを使用します。一方、Microsoftのように思われ、おそらく世界の他の地域ではEntity FrameworkとWCF Data Servicesが前進しています。MSDNで、マイクロソフトがベストプラクティスと見なしているデータアクセステクノロジーを示すものは何も見つかりませんでした。 マイクロソフトには好みがありますか?現在、ほとんどの人はどのデータアクセスを使用していますか?ADO.NETクラシックにとどまり、Entity Frameworkに移行しない正当な理由はありますか?

5
同僚にExcelを超えるデータベース+アプリケーションソリューションの利点を示すために利用できる方法は何ですか?
私はどこにでもExcelスプレッドシートがある会社で働いています。私の同僚はプログラマーではないので、彼らは自分のデータを管理するより良い/簡単/生産的な方法があるかもしれないとは考えていなかったと確信しています。当然、さまざまなスプレッドシートに現在配布されているさまざまなワークフローのニーズに合わせて調整された、リレーショナルデータベースおよびインタラクティブフロントエンドにある機能を活用できる種類のアプリケーションを提唱しています。 私が抱えている問題は、そのようなシステムのメリットをさまざまな関係者に説明しようとしたことですが、実際にゼロから書くのではなく、それらを納得させるのに苦労しています。一般に人々はExcelを理解しています(パワーユーザーでなくても)が、「データベース」という単語が表示されたり、「コード」について話し始めると、すべてが曖昧になる可能性があります。 スプレッドシートから実際のアプリケーションに切り替えることでワークフローがどのように改善されたかを示す証拠とともに、誰かが方法を提案できますか?

8
リレーショナルデータベースでシングルトンをモデル化する最良の方法
Webアプリケーション用のリレーショナルデータベーススキーマを設計するとき、1つの行と1つの行のみを含むテーブルを作成する場合がよくあります。それはそれを設計する間違った方法のように感じますが、私は大幅に良いものを思い付くことができません、またはそれは明らかに「それを行うための正しい方法」です。 最近の例は、ユーザーがホームページのコンテンツを手動で制御できるサイトです。さて、ホームページは1つしかありません。説明テキストを含む領域のテキストフィールドなど、ホームページを作成するために必要なすべてのフィールドを持つテーブルを作成しました。大きな画像ファイルの名前を保存するフィールド。ホームページなどで紹介される記事を指すいくつかの外部キー。それは機能しますが、1行だけのテーブルがあるのは間違っているように感じます。 過去に、ホームページのテーブルで複数の行を許可したり、ランダムに1つの行を選択するなど、他の多くのデザインを試しました。「active」という名前のブールフィールドを追加して、アクティブなホームページの1つをランダムに選択しようとしました。アプリケーションロジックで、常に1行のみをアクティブにしようとしました。ホームページテーブルを作成せず、記事などの他のすべてのアイテムにfeatured_on_homepageのような名前のブールフィールドを持たせることさえしませんでした。 ほとんどの場合、設定ファイルに一連の定数を含むホームページを作成できます。設定ファイルの主な問題は、開発者が制御できることです。ホームページの内容のようなものはユーザーが編集するものなので、データベースに入れなければなりません。 多くのサイトでは、5つの最新記事を選択するなどのクエリを使用してホームページのようなものを作成できるため、この問題はありません。しかし、厳密な要件で手動でキュレーションされたページがある場合、データベースでモデル化するのは難しいです。しかし、写真の表と記事の表があるとします。要件は、ホームページにユーザーが手動で制御する写真を正確に5つ、記事を3つ、任意のテキストのブロックを2つ表示することです。データベースでそれを正しい方法でどのようにモデル化しますか? また、ホームページだけでなく、他の多くのケースでもこのモデリングの問題があります。これは、私が思いつく最も簡単で最も一般的に適用可能な例です。

2
visualstudioデータベースプロジェクトをデータベースと同期させるにはどうすればよいですか?
データベーススキーマをVisual Studio .dbprojデータベースプロジェクトと同期させたいのですが。 現在、ほとんどのデータベース開発作業にSSMSを使用しています。dbスキーマと.dbprojを同期する必要がある場合は、Visual Studioのスキーマ比較ツールを手動で使用する必要があります。なぜこれが必要なのでしょうか?なぜなら: 変更をチェックインする唯一の方法です 変更を適用する唯一の方法です そうしないと、ファイルを取得するときにマージの問題が発生します(基本的に、「最新の取得」にチェックアウトせずに更新しているdbオブジェクトのdb変更が含まれている場合、マージはトリガーされず、簡単に実行できますどのバージョンがどのバージョンであるかを追跡します) スキーマの最新バージョンでVisualStudioの検索機能を使用できることは素晴らしいことです 検索結果を使用して、VSからストアドプロシージャを変更できると便利です(通常、ファイルの名前を変更した場合)。 「スキーマ比較」ツールを自動化して5分ごとに実行する(「クリーン」なソリューションとは思えない)こと以外に、これを実現する方法はありますか? 可能であればSSMSを使用し続けたいのですが、Visual Studioの「サーバーエクスプローラー/データベース接続」を使用して行われた変更を.dbprojに自動的に伝達する方法にも興味があります。

4
ストアドプロシージャの命名規則 [閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 シニア開発者の一人は、「verbObject」タイプの命名(「GetMemberByID」)ではなく、「objectVerb」スタイルの命名(「MemberGetById」)などのストアドプロシージャの命名規則を使用する必要があると述べています。この標準の理由は、関連するすべてのストアドプロシージャがアクションではなくオブジェクトごとにグループ化されることです。 このように名前を付ける方法のロジックはわかりますが、この方法で名前が付けられたストアドプロシージャを見たのは初めてです。命名規則についての私の意見は、名前は自然に読むことができず、単語が何を言っているのか、手順が何をするのかを判断するのに時間がかかるというものです。 これについてどう思いますか?ストアドプロシージャに名前を付けるより一般的な方法はどれですか?また、どのタイプのストアドプロシージャの命名規則を使用しましたか?

5
Webアプリケーションのクライアントごとに新しいテーブルを作成することは良い考えですか?
これは半仮説であり、大規模なデータベーステーブルを処理した経験がないため、何らかの理由でこれが恐ろしいかどうかはわかりません。状況について: 20,000のクライアントがあり、各クライアントがテーブルに1000以上のエントリを持つWebベースのアプリケーションを想像してみてください。これは2,000万行であり、複雑なクエリの速度を確実に低下させる可能性があります。 このような場合、クライアントごとにデータベースに新しいテーブルを作成する方が理にかなっていますか?2万(またはそれ以上)のテーブルがある場合、データベースはどのように反応しますか?

3
2つのリレーショナルテーブルに個別のマッピングテーブルを作成する場合の利点
さまざまなオープンソースCMSで、2つのリレーショナルテーブルをマッピングするための個別のテーブルがあることに気付きました。カテゴリや製品と同様に、別のproduct_category_mapping表があります。このテーブルには、主キーと、カテゴリおよび製品テーブルの2つの外部キーがあります。 私の質問は、どちらかのテーブルで外部キーを定義することによってテーブルを直接リンクするだけでなく、このデータベース設計の利点は何ですか?それは単に便宜の問題ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.