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

過去2つの会社では、Webアプリを介してデータを照会するためにREST APIを使用していました。すなわち。Webアプリに直接SQLを実行させる代わりに、REST APIを呼び出し、SQLを実行して結果を返します。 私の質問は...なぜこれが行われるのですか？ 第三者にさらされるとしたら、理解できました。完全なDBよりも制限されたREST APIを公開する方が適切です。しかし、これらの企業の両方ではそうではありません。 これらのREST APIを使用すると、DBMSを簡単に切り替えることができるようになりました。しかし、それはデータベース抽象化レイヤー（DBAL）のポイントではありませんか？ORMをDBALとして使用するか、生のSQLを記述し、必要に応じてDBALにDB固有のものを変換させることができます（たとえば、MySQLのLIMITをMSSQLのTOPに変換します）。 いずれにせよ、それは私には不要のようです。また、問題の診断も難しくなると思います。Webアプリのレポートが間違った数値を提供している場合、SQLクエリをダンプすることはできません。RESTURLをダンプしてから、REST APIとして機能するプロジェクトに移動して、そこからSQLを取り出す必要があります。そのため、診断プロセスの速度を低下させる間接的な余分なレイヤーです。

32 database  web-applications  rest  web-api 

Windows / Linuxがリレーショナルデータベース（RDBMS）を使用しないのはなぜですか？ ファイルシステムを使用してすべてのデータを保存していることは知っていますが、Webサイト/ Webアプリで使用しているようなデータベースを使用する方が効率的だと思いませんか？ ストレージ用のデータベースを介したファイルシステムの使用について詳しく説明してください。 これは、テキストファイルからのデータの解析よりもデータベースの使用を優先すべき場合の重複ではありませんか？私はオペレーティングシステムのコンテキストのみの観点から話しているが、その質問は一般化されている。

32 database  windows  linux  operating-systems 

次の問題があります：200万件を超えるレコードを含むデータベースがあります。各レコードには文字列フィールドXがあり、フィールドXに特定の文字列が含まれるレコードのリストを表示します。各レコードのサイズは約500バイトです。 より具体的にするために、アプリケーションのGUIには、文字列を入力できるテキストフィールドがあります。テキストフィールドの上に、テキストフィールドの文字列に一致する（最初のN、たとえば100）レコードを表示するテーブルがあります。テキストフィールドに1文字入力または削除すると、テーブルの内容をその場で更新する必要があります。 適切なインデックス構造やキャッシュを使用してこれを行う効率的な方法があるのだろうか。上記で説明したように、クエリに一致する最初のN個のアイテムのみを表示します。したがって、Nが十分に小さい場合、データベースから一致するアイテムをロードすることは大きな問題ではありません。さらに、アイテムをメインメモリにキャッシュすると、検索が高速になります。 主な問題は、パターン文字列を指定して、一致するアイテムをすばやく見つける方法だと思います。DBMSの機能に依存することはできますか、それともインメモリインデックスを自分で構築する必要がありますか？何か案は？ 編集 私は最初の実験を実行しました。レコードを異なるテキストファイルに分割し（ファイルあたり最大200レコード）、ファイルを異なるディレクトリに配置しました（1つのデータフィールドの内容を使用してディレクトリツリーを決定しました）。最終的に、約40000個のディレクトリに約50000個のファイルが作成されます。次に、Luceneを実行してファイルのインデックスを作成しました。Luceneデモプログラムを使用した文字列の検索は非常に高速です。分割とインデックス作成には数分かかりました。これは、クエリしたい静的なデータセットであるため、私にはまったく受け入れられます。 次のステップでは、Luceneをメインプログラムに統合し、Luceneから返されたヒットを使用して、関連するレコードをメインメモリにロードします。

32 database  algorithms  data-structures  indexing 

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

31 database  web-applications  database-design  synchronization 

アリスとボブが両方とも商品リストを編集しているeコマースサイトを考えてみましょう。アリスは説明を改善し、ボブは価格を更新しています。同時にAcme Wonderウィジェットの編集を開始します。ボブは最初に終了し、製品を新しい価格で保存します。アリスは説明を更新するのに少し時間がかかり、完了すると、新しい説明で製品を保存します。残念ながら、彼女は価格を古い価格で上書きしますが、これは意図していませんでした。 私の経験では、これらの問題はWebアプリでは非常に一般的です。一部のソフトウェア（Wikiソフトウェアなど）にはこれに対する保護があります-通常、2番目の保存は「編集中にページが更新されました」で失敗します。しかし、ほとんどのWebサイトにはこの保護がありません。 コントローラーメソッド自体がスレッドセーフであることに注意してください。通常、データベーストランザクションを使用します。これにより、アリスとボブがまったく同じ瞬間に保存しようとしても、破損を引き起こさないという意味で安全になります。競合状態は、アリスまたはボブがブラウザに古いデータを持っていることから生じます。 このような競合状態をどのように防ぐことができますか？特に、私は知りたい： 使用できるテクニックは何ですか？たとえば、最終変更時刻の追跡。それぞれの長所と短所は何ですか。 役立つユーザーエクスペリエンスとは何ですか？ この保護はどのフレームワークに組み込まれていますか？

31 database  web-applications 

私は、すべてのデータアクセスにストアドプロシージャのみを使用している会社で働いています。そのため、新しいプロシージャを実行する必要があるコミットごとにローカルデータベースの同期を維持するのは非常に面倒です。私は過去にいくつかの基本的なORMを使用しましたが、この経験ははるかに優れており、よりクリーンです。今後の開発のために何らかのORMを使用することを検討していることを開発マネージャーとチームの残りに提案したいと思います（チームの残りはストアドプロシージャに精通しており、他のことは一度も使用していません）。現在のアーキテクチャは、.NET 1.1のように記述された.NET 3.5です。ActiveRecordの奇妙な実装を使用し、コードビハインドファイルでループされる型指定のないDataSetを返す「ゴッドクラス」を使用します。クラスは次のように機能します。 class Foo { public bool LoadFoo() { bool blnResult = false; if (this.FooID == 0) { throw new Exception("FooID must be set before calling this method."); } DataSet ds = // ... call to Sproc if (ds.Tables[0].Rows.Count > 0) { foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString(); // other properties set …

31 c#  database  orm  stored-procedures 

「NoSQL」という名前はあまり説明的ではないので、私は本当に嫌いです。データベースを教えてくれますていない私は、データベースが何でもっと興味ところです。このカテゴリには、データベースのいくつかのカテゴリが含まれていると思います。各データベースが最適なツールであるジョブの一般的なアイデアを取得しようとしています。 私がしたい（そしてあなたに作るように頼む）いくつかの仮定： これまでに存在したすべてのデータベーステクノロジーを平等に経験した優秀なエンジニアを何人も雇うことができると仮定します。 特定のデータベースをサポートするための技術的インフラストラクチャがあると仮定します（利用可能なサーバーと、そのデータベースをサポートできるシステム管理者を含む）。 各データベースには無料で可能な限り最高のサポートがあると仮定します。 経営陣から100％の賛同を得ていると仮定します。 問題を投げるのに無限のお金があると仮定します。 今、私は上記の仮定がデータベースの選択に関係する多くの有効な考慮事項を排除することを理解しますが、私の焦点は純粋に技術的なレベルで仕事に最適なデータベースを見つけることにあります。したがって、上記の仮定を考えると、質問は次のとおりです。各ジョブ（SQLとNoSQLの両方を含む）はどのジョブにとって最適なツールであり、その理由は何でしょうか。

31 sql  database  nosql 

ユーザーが独自のWebベースのフォーム（テキストボックス、選択など）を作成し、ユーザーが入力できるようにWebに公開できるとします。 動的なフォームに結び付けるためにデータベースを設計する方法に関するリソースやアドバイスはありますか？ たとえば、フォームごとに子テーブルを作成しますか、または特定のフォームの異なるバージョンを作成しますか？

30 architecture  database  webforms 

現在、私はクライアントに学校入学システムの開発を要求しています。今、これはこの種の挑戦をしている私にとって初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。 私はあなたのほとんどすべてが複雑なソフトウェアを作成したことを知っています。これについてあなたのアドバイスが欲しいです。最初にフロントエンドまたはバックエンドを設計する必要がありますか？ ありがとう！ ここに、私が少し前にインターネットで見つけた記事の結論があります。共有したいだけ 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 

いくつかの非常に大量の時系列データを保存し、クエリできるようにする必要があります。 データのプロパティは次のとおりです。 シリーズ数：約12.000（1万） データポイントの数、グローバル：1か月あたり約500.000.000（5億） 混合値タイプ：データポイントの大部分は浮動小数点値で、残りは文字列です サンプリング期間：シリーズ間およびシリーズ内で可変 タイムスタンプ：ミリ秒精度 データ保持期間：数年、減衰またはダウンサンプリングなし データアーカイブはほぼリアルタイムで構築する必要がありますが、妥当な遅延（約1時間）が許容されます 必要に応じて過去のデータを再構築できますが、高コストです 時々ですが、ごくまれに、過去のデータを更新する必要があります 想定されるクエリのプロパティ： データに対するクエリのほとんどはタイムスタンプベースのクエリです。1日から数ヶ月/年までの範囲。90％以上が最新データのクエリになります その他の要件： ソリューションは、無料のビールのように無料である必要があり、できればオープンソース 私が最初に考えたのは、SQLデータベースの代わりにバックエンドを格納するHDF5ファイルで PyTables / Pandasを使用することでした。 質問： PyTables / Pandasが「最良の」ルートであると仮定すると、それぞれが特定の期間にわたる複数のHDFファイルにデータを分割するか、すべてが単一のファイルに入れられて巨大になるのが良いでしょうか？ 固定形式または表形式を選択する必要がありますか？私にとっては、1か月に1つのHDFファイルを保持すれば、固定形式は問題なく見えます。このように、シリーズ全体がおそらくRAMに収まり、テーブル形式インデックスを必要とせずにメモリ内をスライスできるからです。私は正しいですか？ それが最善のアプローチではない場合、このデータストアをどのように構成する必要がありますか、またはどのテクノロジーを検討する必要がありますか？大量の時系列データの保存に取り組むのは私が初めてではありませんが、この課題を解決する一般的なアプローチは何ですか？ 私が検討した他のアプローチ： 配列データベース：配列の開始時間と終了時間、およびサンプリング周期を保存するだけでよく、配列自体の値とインデックス付けが簡単なので、一定のサンプリング周期を持つ時系列に最適です。しかし、シリーズ自体の可変サンプリング期間では、タイムスタンプと値の関係をより厳密に保つ必要があります。これは、私の見解では、配列DBMSにはあまり適していません。 タイムスタンプ、paramID、値を列として持つ標準SQLデータベースですが、その性質上、クエリに対して大量のディスクI / Oを要求します

27 database  python  performance 

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

26 database  database-design 

これは少し自由な質問ですが、インラインSQLスクリプトが標準である世界で育ったので、私はいくつかの意見が欲しかったので、SQLインジェクションに基づく問題と、SQLがどれほど脆弱であるかをすべて非常に認識しましたあらゆる場所で文字列操作を行います。 次に、クエリをORMに説明し、独自のSQLを生成させるORMの夜明けが来ました。多くの場合、これは最適ではありませんが、安全で簡単です。ORMまたはデータベース抽象化レイヤーのもう1つの良い点は、SQLがデータベースエンジンを念頭に置いて生成されたため、Hibernate / NhibernateをMSSQL、MYSQLで使用でき、コードが変更されることはなく、構成の詳細だけであったことです。 マイクロORMがより多くの開発者を獲得しているように見える今日に早送りします。なぜインラインSQLの主題全体でU-Turnを採用したように見えるのか疑問に思いました。 ORM構成ファイルがなく、より最適な方法でクエリを作成できるというアイデアが好きであることを認めなければなりませんが、SQLインジェクションなどの古い脆弱性に立ち向かうように感じており、データベースエンジンが1つなので、ソフトウェアで複数のデータベースエンジンをサポートしたい場合は、文字列のハッカーをさらに実行する必要があり、コードが判読不能で壊れやすくなります。（誰かが言及する前に、ほとんどの場合、SQLインジェクションからの保護を提供するほとんどのマイクロオームでパラメータベースの引数を使用できることを知っています） それでは、この種のことについての人々の意見は何ですか？この例ではDapperをMicro ORMとして使用し、NHibernateをこのシナリオでは通常のORMとして使用していますが、各フィールドのほとんどは非常によく似ています。 私の用語インラインSQLソースコード内のSQL文字列です。以前は、ロジックの基本的な意図を損なうソースコードのSQL文字列をめぐる設計上の議論がありました。そのため、静的に型付けされたlinqスタイルクエリが非常に人気があり、まだ1つの言語でしたが、1つのページでC＃とSql 2つの言語が生のソースコードに混ざりました。明確にするために、SQLインジェクションはsql文字列の使用に関する既知の問題の1つにすぎません。パラメーターベースのクエリでこれが発生するのを防ぐことができることは既に述べましたが、次のようなソースコードにSQLクエリを埋め込むことに関する他の問題を強調しますDBベンダーの抽象化の欠如、および文字列ベースのクエリでのコンパイル時エラーキャプチャのレベルの喪失、これらはすべて、より高いレベルのクエリ機能を備えたORMの夜明けを回避することができた問題です。 したがって、私は個々の強調された問題にはあまり焦点を当てておらず、より大局的には、ほとんどのマイクロORMがこのメカニズムを使用するため、ソースコードに直接SQL文字列を含めることがより受け入れられるようになりました。 micro ormコンテキストのないインラインSQLの詳細ですが、いくつかの異なる視点を持つ同様の質問があります。 https://stackoverflow.com/questions/5303746/is-inline-sql-hard-coding

26 database  sql  orm 

新しいウェブサイトでユーザー名を予約する必要があります。 これらは一般に3つのカテゴリに分類されます 1）誰も持ってはならないユーザー名（例：admin、user、service、help、rootなど） 2）彼らが現れるイベントで予約したい超有名人や会社の名前 3）当社が直接指定したその他の名前。 最初の2つのカテゴリのユーザー名のリストがどこかに存在し、それらを使用することができれば、本当に役立ちます。 誰もがそのようなリストを知っていますか？

26 database  design  data  api-design