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

アジャイルは初めてで、どのように始めればいいのかわかりません。アイデアは、スプリントでプロジェクトの小さな部分を作成することです。しかし、私が取り組んでいるプロジェクトにはデータベースが必要であり、データベースはプロジェクトで何でもできるようにほぼ機能している必要があります。 それでは、アジャイルプロジェクトはこれをどのように処理しますか、データベースを作成することから始めますか？ たとえば、Scrumを使用している場合、ユーザーストーリーをどのように行い、データベースをテストしますか。 コードを必要とするストーリーの中で、dbの一部を実行したいですか。 「ユーザーとして登録する必要があります...」というストーリーがあるとします。このストーリーの一部としてデータベースにユーザーテーブルを作成しますか？ アジャイルは、データベースの設計にどのように役立ちますか？

12 agile  database  scrum  database-design  user-story 

nグラムのデータを保存することについて少しブレインストーミングしたいと思っていました。私のプロジェクトでは、すべての（n -1）データ項目を知っており、適用可能なすべてのnグラムに対する線形補間を使用して統計的にnを推測したい言語の問題を解決しようとしています。（はい、用語集に従ってタグを既知の単語に割り当てるタガーと、未知の単語の単語の種類を推測するサフィックスツリーがあります。ここで説明するnグラムコンポーネントは、曖昧さの解決を担当します。） 私の最初のアプローチは、観測されたすべてのnグラム（n = 1..3、つまりモノグラム、バイグラム、トライグラム）のデータをそれぞれのSQLデータベースに単純に格納し、それを1日と呼ぶことです。しかし、私のプロジェクトの要件は、他のベクトルの長さ（n）を含むように変更される可能性があり、多くの作業（スキーマの更新、アプリケーションコードの更新など）なしにアプリケーションを4グラムに適応させたいです。理想的には、コードを大幅に（またはまったく）変更せずに、4グラムで動作するようにアプリケーションに指示し、特定のデータソースからのデータをトレーニングするだけです。 すべての要件をまとめるには： nグラムのデータを保存する機能（最初はn = {1、2、3}の場合 使用するnグラムの種類を変更する機能（アプリケーションの実行間） nグラムデータを（再）トレーニングする機能（アプリケーションの実行間） データストアを照会する機能（たとえば、A、B、Cを観察した場合、トレーニング済みの4、3、2、1グラムのデータセットを使用して、最も頻繁に観察されるアイテムを知りたい） ほとんどの場合、アプリケーションは読み込みが重くなり、データセットはほとんどの場合再トレーニングされません このソリューションは、.NET Framework（最大4.0）を採用しています では、そのようなタスクに適した設計は何でしょうか？ 各nの SQLサーバー（MSSQL、MySQLなど）によって管理される固定テーブル（たとえば、2グラム、3グラムなどの専用テーブル） または、ドキュメントのキーとして最初のn -1 を保存し、ドキュメント自体にn番目の値と観測頻度が含まれるNoSQLドキュメントデータベースソリューションですか？ または何か違う？

12 .net  sql  database-design  nosql 

質問と回答をデータベースに保存する必要があります。質問は1〜2文ですが、回答は長くなり、少なくとも1段落、おそらくそれ以上になります。 私が今これを行うことを知っている唯一の方法は、SQLデータベースです。ただし、これまでのところ、これらのデータベースはこのタイプまたはサイズのデータ​​には使用されていないため、これが良い解決策であるとは思いません。これは正しい方法ですか、それともこのデータを保存するより良い方法がありますか？生の文字列を保存するよりも良い方法はありますか？

12 database  database-design 

データベース内の各住所のタイムゾーンの収集を開始したいと考えています。タイムゾーンを保存するためのベストプラクティスは何ですか？既存の住所レコードのタイムゾーンを取得するにはどうしますか？ Microsoft SQLサーバー、.net mvc、C＃を使用しています。任意の提案をいただければ幸いです。

12 database  database-design  time 

私はこの同じ問題に何度も遭遇しましたが、私が本当に最適だと感じた解決策は見つかりませんでした。 アプリで言うと、順序付けられたリストがあり、ユーザーがドラッグアンドドロップなどでその順序を変更できるようにします。順序の変更を保持したい場合。どのようにモデル化しますか？ 順序付きリストリソースの安らかなサービスを設計するにはどうすればよいですか？ 具体的には、どのように私が設計する必要がありますlistし、item安らかなリソースのモデルを？私が見た最も一般的なデザインは、またはプロパティitemを持つエンティティです。私が聞いた別のアプローチは、アイテムの二重リンクリストです。orderposition データベースへの書き込みが多すぎず、クライアントの更新と読み取りが一般に高速なアプローチとは何ですか？エンドポイントはどのように公開されるべきですか？

11 rest  database-design  data-structures  data-modeling 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 序文 私の目的は、サブスクリプションを管理するために、複数のプロジェクト用の再利用可能なコードを作成し（そしてgithubで公開することです）。ストライプと定期請求プロバイダーについては知っていますが、このモジュールが目指しているのはそれではありません。アカウントの残高を計算するためのラッパー/ヘルパー、サブスクリプションを更新するための簡単な通知、および価格計算を処理するための単なるラッパー/ヘルパーでなければなりません。 プロバイダーまたは支払いの可能性が不十分またはまったくサポートされていないか、高額すぎる（マイクロペイメント）ため、繰り返し請求を使用できない国があります。また、定期的な請求を使用したくないが、年末に請求書を手動で支払う/請求書を保存する人もいます。したがって、PayPalの定期的な請求、繰り返しまたは同様のサービスを提案しないでください。 状況 サブスクリプションプランにサブスクライブできるモデルがあるとします（例：）User。このモデルには、現在サブスクライブしているサブスクリプションプランの識別子を格納するフィールドがあります。そのため、計画が変更されるたびに、変更が記録されます。 SubscriptionPlanChanges前述の変更を記録する次のフィールドを持つモデル（など）があります。 subscriberサブスクライブモデルに関連する（Userこの場合） from_plan モデルが変更前に持っていたプラン識別子を定義する to_plan モデルが現在選択しているプラ​​ン識別子を定義する created_at 変更を保存する日時フィールドです valid_until 実際のサブスクリプションが有効になるまで日付を保存します paid_at また、サブスクリプションが支払われたかどうか（およびいつ支払われたか）を定義する日時フィールドです。 もちろん、そのレイアウトは議論可能です。 アカウント残高の質問 ユーザーがサブスクリプションプランを変更する場合、プランフィールドを比較し、価格を取得し、現在のプランvalid_untilとその価格に基づいて新しいプランの控除を計算する必要があります。説明：プランAの1年間をサブスクライブしましたが、6か月後にプランBにアップグレードすると、プランAの6か月の支払額の半分が差し引かれます。 私が不思議に思っているのは、ユーザーが無料プランに切り替える場合など、ユーザーが再度切り替えたい場合に控除できるクレジットを持っていることです。その値を追加のフィールドにキャッシュするか、そのユーザーに関連するすべてのレコードを毎回計算しますか？テーブルのレイアウトについて何か追加/変更しますか？ わかりやすさの質問 サブスクリプション期間の終わりが来ると、ユーザーは通知を受け取り、再度支払うことでサブスクリプションを更新する可能性があります。最も簡単な方法は、更新するだけpaid_atでvalid_until、新しいサブスクリプションオプションを使用することです。ただし、支払い/購読履歴など、誰かが必要とする可能性のあるすべてのデータを保存するかどうかはわかりません。 別のオプションは、このための追加レコードを作成するだろうfrom_planとto_plan（したがって、「変化なし」を象徴しない）同じ識別子を持っているし。しかし、それは何らかの形で口座残高の計算を妨げませんか？ そのようなサブスクリプションを処理するロジックについて誰かが私を正しい方向に向けることができたら、とても感謝しています。 更新 今では助けてくれてありがとう。私の質問はあまりにも曖昧だったので、抽象化を少なくして、より正確になろうと思います。残念ながら、まだ問題を解決できませんでした。 ケースA Userはを選択できますSubscription Plan A。これは現在SubscriptionPlanChange、それを追跡するために保存されます。たとえば5か月後User、サブスクリプションをにアップグレードしますSubscription Plan B。そのため、彼は新しいサブスクリプションの価格を支払い、未使用の7か月のプランaの価格を差し引きます。 ケースB 3か月後、User彼のに戻りSubscription Plan Aます。彼は支払いをする必要はありませんが、残高を受け取るので、サブスクリプションの終了時に、彼は新しいサブスクリプションのためにその残高を差し引きます。 ケースC Userでは、独立したサブスクリプションプランを持つサブサービスのサブスクリプションプランを選択できます。同じでCase A、Case Bそのサブサービスのサブスクリプションに適用できます。 _Case D_ ユーザーがサブスクリプションの1つをキャンセルします。これにより、彼のバランスが回復します。 私の質問（少なくとも現在）は、主にそのデータを適切に保存する方法に依存しているので、ビジネス分析のためにサブスクリプションの履歴を再現し、残高を計算し、サブスクリプションに基づいて未払いを得ることができます。 また、ユーザーモデル自体などに残高を保存する必要があるかどうか、または保存されていないが保存されたデータ/履歴に基づいていつでも計算できるかどうかもわかりません。 注意すべき点がいくつかありますが、問題が発生することはないと思います。 …

11 database-design  relational-database  programming-logic  payment 

ギターのタブというかなり複雑なデータを操作するWebアプリを構築しています。 As a reference, guitar tabs look like this: Eb|-------------------------------------------------------------------------| Bb|-------------------------------------------------------------------------| Gb|--5-5-5-5----------------------------------------------------------------| Db|--5-5-5-5--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-| Ab|--3-3-3-3--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-| Eb|-----------1-1-1-1--5-5-5-5--3-3-3-3--0-0-0-0--1-1-1-1--0-0-0-0--3-3-3-3-| このデータを大きなチャンクとして保存するか、それを分割して「メモごと」に保存する方が、パフォーマンスにとってより効率的でしょうか？ As a use case: User changes first chord from: to: Eb|--- Eb|--- Bb|--- Bb|--- Gb|--5 Gb|--4 Db|--5 Db|--4 Ab|--3 Ab|--2 Eb|--- Eb|--- ブロックとして保存する場合、タブを操作するコードははるかに複雑になります。メモごとに保存すると、データベースにさらにアクセスする必要があります。どの方法がより効率的ですか？多くのユーザーがデータを変更する可能性があります。最高のパフォーマンスのWebアプリが欲しい。回答にまったく影響がある場合は、MySQLを使用します。

11 database-design 

一般的に次の状態を経る自動化されたプロセスがあるとしましょう。スケジュール済み-開始済み-検証中-実行中-完了 その上、これらのプロセスは、エラーまたは明示的なユーザーのキャンセルにより、途中で終了する可能性があります。 私の最初の衝動は、単純にエラーを追加し、可能なステータス値のリストにキャンセルすることですが、結果をステータスから分離する（概念的な）利点について疑問に思っていました（エラーとキャンセルは完了状態とは単に異なる状態）。

11 design-patterns  database-design 

2003年にコンピューティングAレベルを完了し、2007年にコンピューティングの学位を取得し、SQLの使用が多い企業での取引を学び、ストレージにリレーショナルデータベースを使用するというアイデアを思いつきました。 そのため、開発は比較的初心者でしたが、次のようなコメント（/software//q/89994/12436）を読むのに驚きました。 [一部の開発者]は[SQL]を軽deし、それとRDBMSは流行だと思います 明らかに、有能な開発者は適切なジョブに適切なツールを使用し、ストレージ用のフラットファイルまたは別のソリューションが適切な場合にリレーショナルデータベースを作成しませんが、RDBMは非常に多くの状況で役立ちます。流行と考えられますか？

11 programming-languages  database  database-design  relational-database 

PHPとMySQLでメニューシステムを作成しています。いくつかの異なるメニューを用意し、各メニューに一連のメニュー項目を接続します。 サイトでは、別のユーザー権限も持っています。一部のユーザーはすべてのメニューアイテムを表示でき、一部のアイテムは一部のユーザーから非表示になっています。将来、より多くの種類のユーザーを簡単に追加できるように、権限をクリーンな方法で処理する方法に興味があります。 これまでのところ、次のようなものです。 ------------------- |Menus ------------------- |id| |display name| ------------------- ---------------------------------------------------------- |Menu items ---------------------------------------------------------- |id| |menu_id| |label| |link| |parent| |sort| |permission| ---------------------------------------------------------- permission列は、現在のユーザーのアクセス許可IDと照合できるコンマ区切りの文字列のいずれかであると考えています。また、現在存在する権限のすべての可能な組み合わせを定義する他のいくつかのテーブルへの参照である可能性もあります。 1つの解決策は、複数のメニュー項目を単純に格納することでもありますが、唯一の違いは許可ですが、これはストレージの重複を引き起こし、おそらく管理が面倒になります。 これをどのように構成するか、そしてクリーンでダイナミックで無愛想なものと見なすことができるものについての考えを聞いてみたいです。 ありがとう。

11 database-design 

製品ミックスによって価格が異なる会社の新しいPOSに取り組んでいます。 すべての製品に基本価格があります。 私の問題を説明するために、私は次の情報を使用します： Product Category Price A 1 45 B 1 70 Q 2 20 R 2 27 S 2 15 X 3 17 Y 3 22 Z 3 16 会社にはパッケージがあります（パッケージ「コンボ」など）。製品AまたはBの場合、QまたはRのいずれかを選択し、X、Y、またはZのいずれかを選択すると、20ドルの割引が適用されます。 ケースA：注文時にベース商品に追加する場合があります。たとえば、商品Aではなく、商品Qと商品Pを追加して、割引価格のパッケージを作成します。次に、1つのRと1つのZを持つ1つの製品Bが必要であると追加します。 ケースB： 1 Aと2 B、2 Q、1 S、2 Xと1 Zを追加する場合があります。「コンボ」パッケージで規定されているルールに従って、Sはコンボアイテムではないため、2つのコンボのみが適用されます。 その他のプロモーションは数量に依存するため、Bを2つ購入すると20％オフまたは時間に依存し、午後5時以降または午前10時前の場合は10％オフ前にのみ有効です。別のプロモーションは、最後の購入がいつ行われたか、またはY期間に$ Xを超えて購入したかどうかによって異なります。 私の問題： 1）さまざまな要件を持つさまざまなタイプのプロモーションを追加するのに非常に柔軟な方法で、さまざまなパッケージまたはプロモーションを作成できるように、テーブルをどのように構成しますか？ 2）ケースB（またはケースAとケースBの組み合わせ）のように注文した場合、クエリを構造化して、注文に含まれる製品の組み合わせを確認し、それに応じて価格/説明を更新する方法？最終的に、このクエリの最良の結果は、どのパッケージとプロモーションが要件を満たし、その順に顧客に最もメリットがあるかを返します（つまり、注文したものがプロモーション1と3の要件を満たしますが、プロモーション3の方が安価です）。複数のプロモーションで機能する必要があります）。 助けてくれてありがとう！ アップデート＃1 目前の問題をよりよく説明し、これまでに行った作業を更新して問題を解決するために、問題に影響を与えるエンティティと属性に限定された製品モデルのERDを含めています（つまり、ここでは在庫が機能していないため、在庫はありません）エンティティが存在します）。 この質問に影響を与えるエンティティと属性からのサンプルデータも含めています（データの読み取りを簡単にするために、外部キーの代わりに名前/説明を入れています）。 これは、コンボの例を示すフローチャートへのリンクであり、テーブル構造を理解するための高速で視覚的な方法です。 …

11 web-development  database  database-design  schema  relationships 

保存されたデータを検証してデータベースの整合性を保つためにトリガーを使用できることを知っています。ただし、データをデータベースに格納する前に、アプリケーション側でデータの検証を実行してはどうでしょうか。 たとえば、クライアントを保存し、DDLレベルでは簡単に実行できない検証を実行したいとします。 https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics 別の例は監査です。 更新 トリガーとデータベーストランザクションがどのように連携するか。たとえば、挿入されているデータの検証を実行したい場合などです。トランザクション内で行われます。以前に何が起こるか：トランザクションがコミットされるか、トリガーが実行されますか？

10 database  database-design  postgres 

私は定期的に12人の友達と2v2ゲームをプレイしています。ランキングシステムを作成することを目的として、データベースにプレーヤー、チーム、スコア、ゲームを追跡させたいと思っています。 私たちは定期的にチームを変更するので、私はテーブルを作ってみたplayers、teamsそしてgamesゲームは2つのチーム（team1とteam2）を持っているし、チームは2人の選手（player1とplayer2）で構成されています。 これにより、かなりの数の問題が発生します。たとえば、2人のプレーヤー（AとBと呼ぶことにします）を一緒にプレイする場合、プレーヤー1がAでプレーヤー2がBであるか、プレーヤー1がBでプレーヤー2であるチームがすでに存在するかどうかを確認する必要があります。 Aです 列gamesとwinsはplayersテーブルとteamsテーブルの両方にありますが、これは、プレーヤーが勝ったゲームの数だけでなく、プレーヤーがさまざまなチームでどの程度互換性があるか（チームとチームを組んだときにプレーヤーが勝つ頻度）も確認したいためです別の特定のプレーヤー）。 ランキングスコアボード（おそらくEloレーティングシステムを使用します） レーティング、勝利、ゲーム、最近のゲーム統計、および彼が最も互換性のあるプレーヤーを含むすべてのプレーヤーの統計ページ。 これの多くはデータベースの正規化のいくつかの原則に違反していると私は強く疑っています。データベース設計を実装する方法としていくつかの提案が気に入っています。

10 database  database-design 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 Web開発のコンテキストで、誰がデータベースを設計しますか？バックエンドのWeb開発者をサーバー側の処理、データモデリングなどに関連付ける情報のホスト全体にもかかわらず、方程式のデータベース設計の側面は神秘的に存在しないようです。 誰が物理データベースをセットアップするかについては言及していません。データベースの論理モデルを設計し、ユーザーストーリーのインタビューを実施して、必要なフィールド、フィールド仕様などについての情報を入手する人について言及しています。 。 データベースの（PROPER）設計は簡単な作業ではなく（私はこの 672ページャーを読んでいます）、簡単に職業全体になる可能性があることに気付きました。ただし、インターネットを上下に検索しても、Web開発のコンテキストで誰がこのタスクを処理することが予想されるかについては、驚くほど少ない結果しか得られていません。

10 design  web-development  database  database-design 

データベースで非常に高い更新/選択クエリの実行を伴うアプリケーションに取り組んでいます。 ベーステーブル（A）があり、1日のエンティティに対して約500のレコードがあります。そして、システム内のすべてのユーザーについて、このエンティティのバリエーションがユーザーの設定の一部に基づいて作成され、それらは別のテーブル（B）に格納されます。これは、毎日午前0時に実行されるcronジョブによって実行されます。 したがって、テーブルAに10,000人のユーザーと500個のレコードがある場合、その日のテーブルBには500万のレコードがあります。私は常にこれらのテーブルに1日分のデータを保存し、真夜中に履歴データをHBaseにアーカイブします。この設定は正常に機能しており、今のところパフォーマンスの問題はありません。 最近、ビジネス要件にいくつかの変更があり、現在、ベーステーブルAの一部の属性（15〜20レコード）が20秒ごとに変更され、それに基づいて、テーブルBのすべてのバリエーションレコードのいくつかの値を再計算する必要があります。すべてのユーザー。変更するのは20のマスターレコードだけですが、20秒以上かかる200,000のユーザーレコードを再計算して更新する必要があるため、次の更新が行われると、最終的にすべてのSelectクエリがキューに入れられます。オンラインユーザーから約3 getリクエスト/ 5秒で6-9 Selectクエリが発生します。APIリクエストに応答するために、常にテーブルBのフィールドを使用します。 より多くの処理能力を購入してこの状況を解決できますが、100万人のユーザーでも処理できる適切にスケーリングされたシステムに興味があります。 ここの誰かがより良い代替案を提案できますか？nosql +リレーショナルデータベースはここで役立ちますか？ロックせずにデータを頻繁に更新でき、同時にエンティティのさまざまなフィールドで選択クエリを実行できる柔軟性を提供するプラットフォーム/データストアはありますか？

10 database-design  nosql