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

私が提供する4種類のサービスがあると仮定します（それらは頻繁に変わることはほとんどありません）： テスト中 設計 プログラミング その他 上記のカテゴリのいずれかに該当する実際のサービスが60〜80個あるとします。たとえば、「サービス」は「テクニックAを使用したプログラムのテスト」で、タイプは「テスト」です。 それらをデータベースにエンコードしたいです。私はいくつかのオプションを思いつきました： オプション0： VARCHAR直接使用して、サービスタイプを文字列として直接エンコードします オプション1： データベースを使用しますenum。しかし、enumは悪です オプション2： 2つのテーブルを使用します。 service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 参照整合性も楽しむことができます： ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); いいですね。 しかし、私はまだ物事をエンコードし、整数を処理する必要があります。つまり、テーブルにデータを入力するときです。または、テーブルにデータを入力または処理するときに、手の込んだプログラミングまたはDB構造を作成する必要があります。つまり、データベースを直接扱うとき、またはプログラミング側で新しいオブジェクト指向エンティティを作成するときにJOINし、それらを正しく操作することを確認します。 オプション3： 使用しないでくださいenum。2つのテーブルを使用せず、整数列を使用してください。 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

38 database-design  efficiency  enum  normalization 

アプリケーション内の地理的な場所を表す、基礎となるデータモデルの設計は、2つの明確なオプション（またはそれ以上？）を提案します。 自己参照parent_id列ukを持つ1つのテーブル-ロンドン（ロンドンの親ID =英国ID） 外部キーを使用する1対多の関係を持つ2つのテーブル。 私の好みは、必要な数のサブリージョンに簡単に拡張できるため、1つの自己参照テーブルです。 一般に、人々は自己参照テーブルから離れますか、それともA-OKですか？

37 sql  database-design 

同じソースからのデータを使用するアプリケーションが複数あります。ベストプラクティス（または賛否両論）は次のとおりです。 複数のアプリケーションで共有されるデータベースにデータを残す 必要なデータベースは1つだけなのでスペースを節約できます アプリケーションごとにクエリのニーズが異なるため、インデックス作成が複雑になります データをアプリごとのデータベースに毎日インポートする 重複データがアプリごとのデータベースに存在するため、より多くのスペースを使用します 各アプリが個々のニーズに集中できるため、インデックス作成が簡単 他の長所/短所を省いたかもしれませんが、もしあれば、あなたの職場でどのようにこれを行っていますか？

33 database  database-design  multitenancy 

新しいシステムを設計する際に、誰かの名前を考慮すべきであり、人の名前を1つのフィールドとして保存するか、名/姓として別々に保存する必要がありますか？ 単一フィールドの長所： シンプルなUI 非常に長い名前を持つ人の名前を入力しようとしてもあいまいさはありません（多くの場合、姓/名であることが明らかではありません。） タイトルを処理する際の複雑さの軽減（「MD」または「Dr.」を入力するための別のフィールドは不要です） スプリットフィールドの長所： パーソナライズされたコミュニケーションは可能です「Dear Mr X」または「Dear Julie」 消費されたWebサービスが姓/名を個別に必要とする場合、簡単に提供できます。 厳格な身元確認要件のある業界（医療、政府など）に適した選択肢 常に単一フィールドの代替に戻ることができるため、より安全な選択 あなたはどのご覧ください追加の上に一覧表示されていない引数を？ 更新：問題は、ソリューションごとにどの追加（=質問にリストされていない）引数をリストできるかです。賛否両論の可能性の代わりに意見を述べることは、議論を間違った方向に進めると思います。各開発者はこの問題について決定する必要があります。この質問の目的は、必要に応じて評価できる重要な引数のリストを作成することです。

32 database-design  data  domain-model  data-modeling 

非常に機密性の高いデータ（銀行/カードの詳細よりも機密性の高いデータ）を扱うWebサイト/モバイルアプリ/デスクトップアプリを構築しようとしているクライアントがいます。データは機密性が高いため、中央のデータベースに保存したくありませんが、アプリの同期が必要です（モバイルアプリにデータを追加して、デスクトップアプリと同じデータを参照してください）。 これを行うための良い、信頼できる方法を考えることはできませんし、1つあるかどうかはわかりません。それが私がここにいる理由です。誰も私がこのデータをどのように扱うことができるか知っていますか？ 私が考えていた解決策の1つは、アプリ間で何らかの形で同期するクライアント側のデータベースを各アプリに持たせることでした。

31 database  web-applications  database-design  synchronization 

現在、私はクライアントに学校入学システムの開発を要求しています。今、これはこの種の挑戦をしている私にとって初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。 私はあなたのほとんどすべてが複雑なソフトウェアを作成したことを知っています。これについてあなたのアドバイスが欲しいです。最初にフロントエンドまたはバックエンドを設計する必要がありますか？ ありがとう！ ここに、私が少し前にインターネットで見つけた記事の結論があります。共有したいだけ http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 フロントエンド開発者とバックエンド開発者（私の意見） 私の個人的なテイク 繰り返しますが、それは訓練の問題であり、いくつかの広範なストロークの一般化です： フロントエンド開発者 通常、CS学位を取得していないか、3級学校のCS学位を取得していません。 基本に似た言語で作業する（PHP is Basicを参照） フォトショップドキュメントをCSS / HTML /などに変換する視覚的なスキルを持っている。 型のない言語のため、反復プログラミングに対して高い許容度を持っている バックエンド開発者 CSの学位または豊富な経験がある 問題解決のアプローチをより体系的にする 漏れているオブジェクトを見つけるのに何日も費やすことを気にしないでください 問題を解決するためのツールを試してビルドする

30 design  database  database-development  database-design  front-end 

議論のために、FourSquareのシナリオを考えてみましょう。 シナリオ エンティティ： ユーザー 場所 関係： チェックイン：ユーザー<->場所、多対多 友人：ユーザー<->ユーザー、多対多 データベース設計 これらにはエラーが発生する可能性が高いため、指摘してください。 RDBMS テーブル： ユーザー 場所 チェックイン（ジャンクション） 友達（ジャンクション） 長所： CAP：一貫性、可用性 短所： CAP：パーティション許容値、別名シャーディング スキーム=柔軟性のない構造 貧弱な複製？ グラフ オブジェクト： ユーザー 場所 エッジ： 友達：ユーザー<->ユーザー チェックイン：ユーザー->場所 タイムスタンプを含む 長所： CAP：一貫性、可用性？ スキーマレスで簡単に変更可能なオブジェクトとエッジ グラフトラバーサルクエリ、たとえば： クラスタリング 友達のグループを見つける 似たような人が好きなレストランを見つける 他の一般的な/有用なクエリはありますか？ 短所： CAP：パーティションの許容範囲？ ドキュメント/オブジェクト 3つの個別のデータベース？ ユーザー 友達リスト チェックイン タイムスタンプ ユーザー 場所 場所 長所： …

29 database  database-design  relational-database  document-databases  graph-databases 

Drupal 7、Wordpress（非常に古いバージョン）、Pythonベースのカスタムアプリケーションなど、いくつかの有名なCMSのSQLダンプを参照しています。 これらのすべてのダンプには、整数の代わりに文字列フラグを持つデータが含まれていました。例えば、ポストの状態は次のように表現されたpublished、closedまたはinheritよりむしろ1、2または3。 データベースの設計の経験はかなり限られており、単純なSQLを使用したことは一度もありませんが、このようなデータには数値/整数フラグを使用する必要があることを常に教えられました。tinyintたとえば、データベース内で消費するスペースがの場合よりもはるかに少ないことは明らかですvarchar(9)。 だから私は何が欠けていますか？これはデータストレージとデータの冗長性の浪費ではありませんか？これらの列が文字列ではなく整数を使用している場合、ブラウジング、検索、およびインデックス作成が少し速くなりませんか？

29 database  database-design  sql  strings 

私は、世界中のさまざまな顧客向けに高度にカスタマイズされた大規模なソフトウェアプロジェクトに取り組んでいます。つまり、80％のコードがさまざまな顧客に共通しているだけでなく、ある顧客から別の顧客に変更する必要がある多くのコードがあることを意味します。過去に別のリポジトリ（SVN）で開発を行い、新しいプロジェクトが開始されたとき（大規模な顧客はほとんどありませんが）、過去のプロジェクトがニーズに最適なコードベースに基づいて別のリポジトリを作成しました。これは過去に機能していましたが、いくつかの問題に遭遇しました。 あるリポジトリで修正されたバグは、他のリポジトリでは修正されません。これは組織の問題かもしれませんが、5つの異なるリポジトリのバグを修正してパッチを当てるのは難しいと思います。このリポジトリを保守しているチームは世界の別の場所にいて、テスト環境がないことに注意してください、スケジュールや要件を把握していません（ある国の「バグ」は別の国の「機能」かもしれません）。 別のプロジェクトにも役立つかもしれない1つのプロジェクトに加えられた機能と改善は失われ、別のプロジェクトで使用された場合、多くの場合、1つのコードベースから別のコードベースにそれらをマージする大きな頭痛の種を引き起こします）。 1つの開発ブランチで行われたリファクタリングとコードの改善は、ブランチ間でこれらのすべての変更をマージする必要がある場合、失われるか、害よりも害をもたらします。 現在、これらの問題を解決する方法について議論しており、これまでのところ、これを解決する方法について次のアイデアを思いつきました。 開発を別々のブランチで維持しますが、一般的なバグ修正がマージされる中央リポジトリを持ち、すべてのプロジェクトがこのセントラルリポジトリからの変更を定期的に（たとえば毎日）独自のものにマージすることで、より整理されます。これには、大きな規律と、ブランチ間のマージに多大な労力が必要です。ですから、特に時間のプレッシャーがかかったときに、それがうまくいくと確信していません。 個別の開発ブランチを放棄し、すべてのコードが存在する中央のコードリポジトリを持ち、プラグ可能なモジュールと構成オプションを使用してカスタマイズを行います。既にコードの依存関係を解決するためにDependency Injectionコンテナーを使用しており、ほとんどのコードでMVVMパターンに従ってビジネスロジックをUIから明確に分離しています。 2番目のアプローチはよりエレガントに見えますが、このアプローチには多くの未解決の問題があります。例：モデル/データベースでの変更/追加の処理方法。エンティティフレームワークで.NETを使用して、エンティティを厳密に型指定しています。ある顧客には必要だが、データモデルを乱雑にすることなく別の顧客には役に立たないプロパティをどのように処理できるかわかりません。サテライトテーブル（特定のエンティティ用の追加の列が元のエンティティへの1：1マッピングで存在する個別のテーブルを持つ）を使用してデータベースでこれを解決することを考えていますが、これはデータベースのみです。これをコードでどのように処理しますか？データモデルは中央ライブラリにあり、このアプローチを使用して顧客ごとに拡張することはできません。 この問題に苦しんでいるのは私たちだけではないと確信しており、このトピックに関する資料がほとんどないことにショックを受けています。 私の質問は次のとおりです。 高度にカスタマイズされたソフトウェアに関してどのような経験があり、どのアプローチを選択し、どのように機能しましたか？ どのアプローチをお勧めしますか、またその理由は何ですか？より良いアプローチはありますか？ お勧めできるトピックに関する良い本や記事はありますか？ 技術環境（.NET、Entity Framework、WPF、DI）について具体的な推奨事項はありますか？ 編集： すべての提案をありがとう。アイデアのほとんどは、すでにチーム内で持っていたものと一致しますが、あなたがそれらで得た経験と、それらをより良く実装するためのヒントを確認することは本当に役立ちます。 どの方向に進むかはまだわかりませんし、（単独で）決定を下すわけではありませんが、チームでこれを伝えて、役に立つと確信しています。 現時点では、テナーはさまざまな顧客固有のモジュールを使用する単一のリポジトリのようです。私たちのアーキテクチャがこれに合っているか、それを適合させるためにどれだけ投資する必要があるのか​​はわかりません。 それで、すべての応答に再び感謝します！

28 design  architecture  development-process  database-design  code-organization 

私は、個人、ユーザー、サービス、クーポン、署名パッケージなどの商業データなど、スタートアップ企業のすべてのサービスの一般的な非機能要件として使用されるデータベースをモデリングしています。 私は性別モデルについて考えています。これらの現代では、主観的なアイデンティティに関する国ごとに異なる法律があるので、それを考慮に入れて、男性と女性のオプション以外の個人エンティティをモデル化する必要がありますか？ オプションは、未定義、未回答、その他、トランスジェンダー...または私が知らないその他の業界標準です... それとも、LGBTの人々は本当に男性でも女性でもないと言って不快になりますか？

27 database-design  domain-model  data-modeling 

いくつかのプロジェクトで、開発者が重要なユーザー情報を1つのテーブル（電子メール/ログイン、パスワードハッシュ、スクリーン名）に、残りの重要ではないユーザープロファイルを別のテーブル（作成日、国など）に保持することを好みます。本質的ではないということは、このデータがたまにしか必要ないということです。明らかな利点は、ORMクエリを使用している場合、より少ないフィールドをクエリすることは明らかに良いことです。ただし、同じテーブルに2つのエンティティをマップすることができます。これにより、不要なものを照会する必要がなくなります（より便利になります）。これらのものを2つのテーブルに保持することの他の利点を知っている人はいますか？

26 database  database-design 

Joshua BlochのEffective Javaの項目の1つは、クラスがインスタンスの変更をできる限り少なくし、できればまったく許可しないという概念です。 多くの場合、オブジェクトのデータは何らかの形式のデータベースに保存されます。これにより、特に大規模システム内の単一のエンティティを表すテーブルについて、データベース内の不変性の考えを考えるようになりました。 私が最近実験しているのは、これらのオブジェクトを表すテーブル行に対して行う更新を最小限に抑え、可能な限り挿入を実行しようとするアイデアです。 最近試したものの具体例。後で追加データを含むレコードを追加する可能性があることがわかっている場合は、それを表す別のテーブルを作成します。次の2つのテーブル定義のようなものです。 create table myObj (id integer, ...other_data... not null); create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null); これらの名前が逐語的ではなく、単にアイデアを示すためであることは、願わくば明白です。 これは、データ永続性モデリングへの合理的なアプローチですか？特に、レコードが最初に作成されたときに存在しなかった可能性のあるデータのNULLを埋めるために、テーブルで実行される更新を制限することを試みる価値はありますか？このようなアプローチが後に激しい痛みを引き起こす可能性があるときはありますか？

26 database-design  immutability 

今日、SQL Serverの最適化に関する本を閲覧していましたが、一定量のアイデアがストレージの線形モデルに基づいているように思われました。SSDのストレージモデルはまったく異なるため、データベースの調整や最適化についての考え方に関して、何らかの形でゲームを変えますか？

26 sql  database-design  optimization  ssd 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 地球上の住所に適した地理的な住所/場所の正しい形式は何ですか？今のところ： 国 シティ 通り 数 テキストデータ（簡単にするため） zip 緯度/経度 しかし、私はそれを改善できると信じています。国の州/地域または地域のようなものがあるかもしれません。または、シンガポールや香港には、地域/地域/州はありません。 通りはないかもしれませんが、道路や大通りなどがあります。多数の建物が複合している場合があります。床があるかもしれません。部屋番号。等....

25 design  database  database-design  database-development 

アプリケーション用のデータベースを設計する際の一般的なベストプラクティスをいくつか知っていますが、再設計についてはどうですか？ 私は「内部」と言っているにも関わらず、内部ビジネスアプリケーションの再設計を担当するチームに所属していますが、残念ながら、システムの実際のユーザーとの接触から多くの層の人々がいます。 現在のプログラムはOracle Formsにあり、非正規化された多数のテーブルに散らばっています。場合によっては、互いのデータにわずかな異形を持つ複数のほぼ重複したテーブルがあります。多くの場合、制約は、適切に実施されていないストアドプロシージャの形式です。型でさえ正しく保存されていないようです。Oracleが無視しているように見えますが、SQL Serverのインポート/エクスポートウィザードに適合する（そして当然のことながら）あらゆる種類の不正なデータに遭遇しました。（たとえば、2桁の整数は完全な日時を構成しません！） 元のプログラムはおそらく20年前に遡り、元の開発者は皆かなり前に退職しているため、ここの年配の人でさえ自分が誰であるかわかりません。その結果、明確な要件をクリアする必要もありません。既存のアプリケーションの機能を複製し、既存のデータを保持するだけです。 書き換えの最終結果は、バックエンド用のMS SQL Serverを備えたASP.NET上で実行されるWebベースのバージョンになります。 私の他の2人の開発チームメイトは、私よりはるかに年上で、どちらもビジネス/ MISのバックグラウンドを持っていますが、私の場合はCSです。シニアメンバーの経験はほとんどOracleフォームのみであり、他のメンバーはほとんどがVisual Basicでビジネスアプリケーションの作業を行っています。私のデータベースの背景は、MySQLまたはSQLiteのプロジェクト用の新しいデータベースの設計に限られていますが、ほとんどは私の学部クラスですが、実際にデータベースを設計した経験があるのは私だけです。 既存のすべてのデータをニュートラル形式に読み込み、再キャストして新しいデータベースに配置する準備ができたC＃で小さなプログラムを既に作成しました。宛先データベースの設計後にロードインコードを記述することで、データを新しい正規化されたテーブルに適切に分割し、新しい順序に従って正しい順序で追加するなどして、同じプログラムを後で実行できるようにする予定です。生産データを実際に新しく展開された再設計にコピーします。これにより、データベースの実際の再設計が主要な問題として残ります。 だから私の質問の中心：既存のアプリケーションのデータベースレベルアップから再設計を行うためのいくつかのベストプラクティスは何ですか？

24 database-design  design