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

（ActiveRecord）モデルに加えて、常にデータベースレベルで制約を適用しています。しかし、私はこれが本当に必要かどうか疑問に思っていましたか？ 少しの背景 私は最近、モデルの基本的な自動タイムスタンプ生成方法を単体テストする必要がありました。通常、テストはモデルのインスタンスを作成し、検証なしで保存します。ただし、テーブル定義でnullにできない他の必須フィールドがあります。つまり、ActiveRecord検証をスキップしてもインスタンスを保存できません。だから私はdb自体からそのような制約を削除し、ORMにそれらを処理させる必要があるかどうかを考えていますか？ db、imoの制約をスキップした場合に考えられる利点 - データベースを移行することなく、モデル内の検証ルールを変更できます。 テストで検証をスキップできます。 考えられる不利益は？ ただし、ORM検証が失敗またはバイパスされる可能性がある場合、データベースは制約をチェックしません。 どう思いますか？ 編集このケースでは、データベースからモデルを生成するYii Frameworkを使用しているため、データベースルールも生成されます（ただし、生成後はいつでも記述できます）。

13 database  orm  validation  dry 

NoSQL対SQLデータベースに関する議論で、スキーマを新しいバージョンに移行するのは問題があるため、企業はスキーマレスのNoSQLデータベースを使用することを好むと聞きます。しかし、アップグレードを行うとき、それは本当に大きな問題ですか？リレーショナルデータベースは、このような操作に悪いですか？ MongoDBブログの次のブログ投稿を読んでください。なぜSchemalessなのですか？

13 database  nosql  relational-database  schema 

PHPとMySQLを使用したWeb開発でプログラミングのキャリアを始めました。ほとんどの動的データといくつかの設定/パラメータデータの保存にdbを使用することに慣れました。多くのデータがある場合もあれば、テーブルのエントリが少ない場合もあります。私にはこれは自然なことのように思えましたが、私が知っている限りでは、これは多かれ少なかれWeb開発で受け入れられるアプローチです。（間違っている場合は修正してください...） 私は現在デスクトップアプリケーションを掘り下げており、私の本来の傾向は、dbを再び使用して、アプリケーションの使用を通じて生成される多くの情報を保存することです。 ただし、私が知る限り、dbを頻繁に使用するアプリケーション（使用しているアプリケーション）は表示されません。 [編集：これは、多くのアプリケーションがプログラム自体に埋め込まれた軽量のデータベースを使用するという点で誤った仮定であると指摘されています。] この理由は何ですか？どの時点でdbを使用するのが適切ですか？この問題に関する基準はありますか？また、dbを使用してデスクトップアプリケーションを開発しない理由は何ですか？

13 database  desktop-application 

この男が言うことに基づいて：http : //toddfredrich.com/ids-in-rest-api.html UUIDを使用してAPIリソースを識別することについて彼が正しいと仮定します。次に、そのように実装しようとすると問題が発生します。これは次のとおりです。 class FooEntity { final String id = null; //auto-generated by my backend (mongodb), not shared final UUID uid = UUID.randomUUID(); //the resource id } （クライアントとサーバー間では、データベースエンティティではなく、送受信されるDTOです。） 問題は、id私がもう使用していないので役に立たないということです。クライアントがリクエストを行うuidので、なぜ2つのIDを処理する必要があるのですか？次に、最初の同じ問題に戻ります。UUIDを主キー（_id）として設定すると、バックエンドIDが公開されます。 そのほかに、効率性のトピックがあります。ObjectIdによるインデックス作成はUUIDよりもはるかに効率的であると読みました。

13 database  api-design  mongodb 

今日、データベースデプロイメントテクニックについて議論しており、現在のプロセスでいくつかの最近の失敗があり、デプロイメントをロールバックしたいが、アプリケーションの古いバージョンが新しいバージョンに対してテストされたことがない状況を見てきましたデータベース。 一方では、バージョンアップ命令とバージョンダウン命令（SQLまたはアプリケーション言語で書かれているかどうか）があり、アプリは到達する必要のあるバージョンを知っている移行スタイルのデプロイメントがあります。 これらは単純であり、あまりロールバックしないため、開発者は単純に熱心です。ただし、フィールド/テーブルを追加していて、ロールバックする前にそのフィールドにデータが入力されると、リスクがあります。さらに悪いことに、以前のバージョンに関連するデータをドロップした場合。 一方、アップグレード、ロールバック、ロールフォワードのアプローチを検討することもできます。このアプローチでは、ロールバックが移行ほど劇的ではありません。たとえば、アップグレードにより、null不可フィールドが追加される場合があります。rollbackはnullを許可するので、古いアプリは気にしません。rollforwardは、nullフィールドにデータを入力し、再びnull不可にします。 これはデータを保持しますが、コーディングとテストの両方が複雑です（残念ながら、自動化された統合テストはほとんど存在せず、修正中に問題が発生します）。 これらの問題を軽減する安全な方法はありますか？他に検討すべきオプションはありますか？後で痛みを和らげることができる悪い経験を共有したいですか？

13 database 

私は比較的大学を卒業していないので、リレーショナルデータベースに関する私の知識のほとんどは、BCNFまたは3NFにないものはすべてわいせつである私のデータベースコースからのものです。確かにそれは極端なことの一端ですが、仕事中の私のチームは本当にそれを完全に反対側に持っているようです。 マイクロサービスdbスキーマでは、エンティティが複数のテーブルを持つことはめったにありません。通常、別のテーブルに正規化するものはすべてjson列に格納されます。このjsonのプロパティの1つをクエリする必要があることが後で発見された場合、新しい列が追加され、データは両方の場所（はい、同じテーブルの2つの異なる列）に保存されます。 多くの場合、これらのjson列には間違いなく利点があります。そのデータを照会する必要がなく、そのデータに一方的な変更を加える必要がない場合（これは明らかに予測できないことです）、それは悪い考えではありません。さらに、当社のサービスの多くは、サーバーを認識しないか、必要なディスク容量のわいせつなマシンでホストされているため、データの重複は大きな問題ではありません。（私が一般的に哲学から避けたいことですが） 現在、所有する一連の条件に基づいてルールに一致するサービスを構築し、ルールが真（たとえば、すべての条件が真）の場合にそれらのルールに関連付けられた一連のアクションを実行します。このサービスを最も迅速に構築している私のサブチームは、スキーマ内のルールから離れてアクションと条件を正規化することには大きなメリットがあると考えています。明らかに、これらのテーブルは、ルールIDとの外部キー関係を維持します。私たちの観点からは、条件でのデータの重複を避けることができ、一度だけ評価されることを保証できます。また、必要なときに必要な条件やルールを見つけやすく、すべてのルールを引き出してメモリ内で検索する必要がありません。 今日、私たちの主任技術者の一人と話して、彼は私をこのスキーマから遠ざけようとしました。私たちが実際にそれを必要としないとあらゆる方法で議論しようとすると、将来的にパフォーマンスの問題が発生し、所有する古いモノリスを参照します。彼は、私たちがやっていることを「古い方法」と呼び、jsonを含むフラットテーブルを「新しい方法」と呼びました。彼は、私が原子性を望む場所ではそれを必要とせず、クエリの代わりにメモリ内でより多くのことをすべきだと主張した。これは、現在当社のサービスの多くが従っている設計原則です。データの量が大幅に増加することは予想していませんが、これによりクエリを高速に保つことができます。予想されるのは、ルールの評価とアクションの実行に多くの時間を費やすことです。 非リレーショナルデータベースが近年人気を博していることは理解していますが、外部キー関係のパフォーマンスへの影響に関する情報を積極的に検索しても、彼の主張を裏付ける情報は多くありません。問題を引き起こす可能性のある大規模なトランザクションを導入する傾向があると思いますが、それは外部キー自体とは無関係の問題のようです。 これは私の素朴ですか？または、これは本当に私と私のサブチームに欠けているものがありますか？解決策を必ずしも探しているわけではないので、問題に関する詳細な情報を明示的に提供していません。それが私たちの大規模なチームで一般的な傾向であることを考えると、彼らがこれで何かに取り組んでいるかどうかは本当に興味があります。

12 database  relational-database  nosql 

データをクラウドに保持するデスクトップアプリケーションを作成しています。私が懸念していることの1つは、アプリケーション内のアイテムの編集を開始し、しばらくそれを残すとデータが古くなることです。これは、2人が同じアイテムを同時に編集しようとした場合にも発生します。編集を終えてデータを保存したい場合、データベースに現在存在するものを上書きするか、最後の変更後に編集を開始したことを確認し、変更を強制的に破棄するか、リスクを与えるオプションを与える必要があります他の人の変更を上書きする。 フィールドis_lockedをlock_timestampDBテーブルに追加することを考えました。ユーザーがアイテムの編集を開始すると、行がis_lockedtrueに変更され、ロックタイムスタンプが現在の時刻に設定されます。その場合、ロックが保持される時間（5分など）があります。他の誰かがアイテムを編集しようとすると、アイテムがロックされ、ロックが自動的に期限切れになるというメッセージを受け取ります。ユーザーがロックの編集中に立ち去ると、比較的短時間でロックが自動的に期限切れになり、ロックが期限切れになったことがユーザーに警告され、データの更新後に強制的に編集が再開されます。 これは古いデータの上書きを防ぐ良い方法でしょうか？それは過剰です（アプリケーションが1つのアカウントで同時に数人以上のユーザーによって使用されるとは考えていません）。 （私が抱えているもう1つの懸念は、2人が同じアイテムのロックを取得することですが、それは私が快適な競合状態だと思います。）

12 database  desktop-application  cloud 

テーブルBと1対1の関係を持つテーブルAがある場合、それらを離しておくことは意味がありますか？または、それらを単一のテーブルに結合しても害はありませんか？これらのシナリオ（2つのテーブルと1つの結合されたテーブル）のいずれかが、通常の形式（1NF、2NF、3NFなど）に関して何か影響を与えますか？

12 database  relational-database  normalization 

注：コードサンプルはc＃で記述されていますが、それは問題ではありません。適切なものを見つけることができないため、c＃をタグとして配置しました。これはコード構造についてです。 Clean Codeを読んで、より良いプログラマーになろうとしています。 私はしばしば、単一の責任原則（クラスと関数は1つのことだけを行うべきです）、特に関数に従うことに苦労しています。たぶん私の問題は、「一つのこと」が明確に定義されていないことですが、それでも... 例：データベースにFluffiesのリストがあります。Fluffyが何であるかは気にしません。クラスに綿毛を回復させたい。ただし、綿毛はいくつかのロジックに従って変化する可能性があります。いくつかのロジックに応じて、このクラスはキャッシュからデータを返すか、データベースから最新のデータを取得します。毛羽立ちを管理していると言えますが、それは一つのことです。簡単にするために、ロードされたデータが1時間有効であり、それを再ロードする必要があるとしましょう。 class FluffiesManager { private Fluffies m_Cache; private DateTime m_NextReload = DateTime.MinValue; // ... public Fluffies GetFluffies() { if (NeedsReload()) LoadFluffies(); return m_Cache; } private NeedsReload() { return (m_NextReload < DateTime.Now); } private void LoadFluffies() { GetFluffiesFromDb(); UpdateNextLoad(); } private void UpdateNextLoad() { m_NextReload = DatTime.Now …

12 c#  database  object-oriented-design  caching  single-responsibility 

MySQL、SQLLite、MSSQLなどのいくつかのタイプのデータベースとインターフェイスできる、より大きなアプリケーションで抽象クラスをどのように設計し始めますか？ このデザインパターンは何と呼ばれ、どこで正確に始まりますか？ 次のメソッドを持つクラスを書く必要があるとしましょう public class Database { public DatabaseType databaseType; public Database (DatabaseType databaseType){ this.databaseType = databaseType; } public void SaveToDatabase(){ // Save some data to the db } public void ReadFromDatabase(){ // Read some data from db } } //Application public class Foo { public Database db = new …

12 c#  database 

データベーステーブルを監視するダッシュボードを作成しています。データベースアクセスのみがあります（アプリケーション層はありません）。テーブルはかなり大きい（1000万行）が、急速には変化しない（1分間に100回の挿入/更新） テーブルが変更されたかどうかを確認するにはどうすればよいですか？私は毎秒データベースにアクセスしようとしますが、これは総当たり的なアプローチのようです... データベース：MySQL / Postgres

12 database  mysql  real-time  postgres 

ユーザー、ユーザーアカウント、ユーザーライセンス、ライセンス価格、請求書など、さまざまなデータにMS SQLを使用するWebアプリケーションを開発しています。 ユーザーのシステムのリアルタイム使用状況をログに記録し、毎月の請求に使用する必要があります。たとえば、ユーザーが特定のページ/ URLを取得するたびにログを記録し、取得したページ数に基づいて月末にユーザーに請求します。 これらのログイベントをMS SQLデータベースのテーブルに書き込む必要がありますか？ これらのログイベントをSQL以外の追加専用ログファイルに書き込む必要がありますか？ これらのログイベントをユーザーごとに異なるログファイルに書き込む必要がありますか？ これは特に大規模なWebサイトではありません。たとえば、最大10,000ユーザーが1日あたり平均5つのログ記録可能なイベントを行う=> 50,000イベント/日= 30イベント/分= 18,000,000イベント/年。 どちらかのオプションが実行可能と思われ、明確な利点があるかどうかわからないので、私は尋ねています。 請求可能なイベントに関連付けられたデータは単純です。たとえば、次のとおりです。 ユーザーID（SQLのユーザーテーブルとの外部キー関係） 日時 請求可能なページのURL この質問に対する私自身の答えは次のとおりです。 データベーステーブルにログを書き込むことの利点： 関係の整合性：たとえば、ログに記録されたイベントは有効なユーザーIDに関連付けられます（ユーザーIDをテーブル間の外部キーとして定義することにより） 課金のために読みやすい：例えばSELECT COUNT GROUP BY、ユーザーごとのログイベントの数のカウントを取得する ログファイルへの書き込みのいくつかの利点： より簡単なパフォーマンス：SQLはあまり頻繁に使用されません。たとえば、ユーザーのログインイベントにのみ使用され、ほとんどが読み取りにのみ使用されます 管理の簡素化：データベースから削除/アーカイブする代わりに古いログファイルを移動することにより、年末などに古いデータを簡単にアーカイブできます 答えが間違っている場合はお知らせください。または何かの重要性を誇張します。またはいくつかの重要な考慮事項を忘れています。 そして/またはそれが私の答えと異なる場合、あなたの答えが何であるかを教えてください。

12 design  web-development  database  performance  logging 

私は、CSVのようなものでは処理が効率的でなく、SQL / MySQLサーバーが多すぎるほど十分なデータを保存する必要がある小さなプロジェクト（本番ではない）に取り組んでいます。.Netには、単一のファイルを読み込んで処理するのではなく、サーバーを管理および接続することなく、クエリ機能を使用して、データの複数のエントリを効率的に保存する方法がありますか。

12 c#  database  sql 

これは基本的に、弱いエンティティとは何かに関する質問ですか？それらをいつ使用する必要がありますか？どのようにモデル化する必要がありますか？ 通常のエンティティと弱いエンティティの主な違いは何ですか？ドメイン駆動設計を行う場合、脆弱なエンティティは値オブジェクトに対応しますか？ ここでトピックに関する質問を続けるのを助けるために、人々がこれらの質問に答えるために使用できるウィキペディアから取られた例です： この例でOrderItemは、弱いエンティティとしてモデル化されましたが、通常のエンティティとしてモデル化できない理由を理解できません。 もう1つの質問は、注文履歴（つまり、ステータスの変更）を追跡したい場合、それは通常のエンティティまたは脆弱なエンティティでしょうか？

12 design  database  database-design  entity 

最近、スタンフォードのCoreNLPを使用して自然言語処理（NLP）の実験を開始しましたが、テキストマイニングアプリケーションなどのNLP解析データを保存する標準的な方法にはどのようなものがありますか？ 面白いと思う方法の1つは、子を隣接リストとして保存し、再帰クエリをうまく利用することです（Postgresはこれをサポートしており、非常にうまく機能していることがわかりました）。 しかし、私は長年にわたってこの分野で働いている人々によって採用されてきた分析の種類に応じて、おそらくこれを行うための多くの標準的な方法があると思います。それでは、NLPで解析されたデータの標準的な永続化戦略とは何ですか？

12 database  parsing  persistence  natural-language-processing