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

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

31 sql  database  nosql 

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

29 database  database-design  sql  strings 

この質問は、SQLとNoSQLの違いに関するものではありません。私は現時点では本当に理にかなっていない何かの理由を探しています（おそらく私の理解や感謝の欠如のため）。 MVC5、Entity Framework 6コード、SQL Server 2008を使用してゼロから新しいプロジェクトを開始しました。アプリケーションコードのビジネスレイヤー内で適用する必要があります。 私の意見では、外部キーはデータ/参照整合性の一部を形成し、実際にはビジネスロジックを模倣していません。ビジネスロジックは、参照を適用する対象/タイミング/方法/理由を制御するプロセスと検証に過ぎません。一意の制約はほぼ間違いなくビジネスプロセスであることを理解できますが、私にとってこれはロジックを補完するだけで、整合性の一部を形成します。 2番目の引数は、データにNoSQLアプローチを採用することです。SQL-Server 2008の使用、レポートの必要性、テラバイトにスケーリングされないデータ、Mongo、Ravenなどのテクノロジーに対する考慮の欠如を考慮すると、これは非常に珍しくて非正統的であることがわかりました。 以前にそのようなシナリオに出くわした人はいますか？なぜ参照データ用に設計されたSQL ServerでNoSQLアプローチを採用し、外部キーを必要としないのですか？

28 sql  sql-server  nosql 

私は、標準のSQLリレーショナルデータベースまたはJSONオブジェクトを使用して、イベントまたはアクティビティに関するデータを保存するかどうかを決定しようとしているプロジェクトに取り組んでいます。 プロジェクトは複数のイベントタイプのデータを保存するため、この質問に対して1つのイベントタイプのみを説明することにしました。 ライブ音楽イベント（この質問の最後にあるJSONスキーマを使用して詳細に説明します）は、イベントが行われる場所、イベントの日時、イベントのコストなどのデータを格納するオブジェクトです。ライブ音楽イベントオブジェクトには、1対1（イベント->名前、イベント->説明）と1対多（イベント->会場、イベント->日付、イベント->チケットタイプの両方があります。 ）関係。さらに、イベントオブジェクトには、パフォーマーオブジェクトにリンクする1つ以上のパフォーマーIDを含めることができます。演奏者オブジェクトは、ライブ音楽イベントで演奏しているミュージシャンのデータを保存します。 データは、単純（「x名前のイベントを検索」）と複雑（「現在の音楽ジャンルから半径「z」以内の「x」音楽ジャンルと「y」コストのイベントを検索」」の両方を使用してユーザーに照会されます場所」）クエリ。データは、ユーザーがWebフォームを使用して送信します。 おそらく定義済みのJSONスキーマからわかるように、私はもともとJSONオブジェクトを使用してこのデータを保存するつもりでしたが、私のデータは純粋にリレーショナルであるため、古いメソッドに固執する必要があると言う人がいます。 私のニーズを考えれば、それぞれのアプローチの長所と短所についてのご意見をいただければ幸いです。明確なものが必要な場合は、お気軽にお問い合わせください。 { "event": { "eventID":{ "type":"string" }, "eventType":{ "type":"array", "eventTypeItem":{ "type":"string" } }, "eventName":{ "type":"string" }, "eventDescription":{ "type":"string" }, "eventVenueList":{ "type":"array", "eventVenueListID":{ "type":"integer" } }, "eventURL":{ "type":"string" }, "eventTwitter":{ "type":"string" }, "eventFB":{ "type":"string" }, "eventInstagram":{ "type":"string" }, "eventEmail":{ "type":"string", "format":"email" }, "eventContactPerson":{ "type":"string" }, …

28 design  sql  json 

キーワードを大文字にしてSQLを作成する開発者が多いようです。 SELECT column FROM table INNER JOIN table ON condition WHERE condition GROUP BY clause HAVING condition なぜ人々はこのアプローチに固執するのだろうか？明らかに、これは長い間確立された慣習ですが、大文字を必要とするRDBMSに出会ったことはありません。 個人的には、キーワードが小文字で正確に記述されているのは、クエリの間違った部分に注意を喚起するキーワードを見つけるためです。 それでも、十分な人がこの慣習を使用しているので、何かが足りないと思うので、この質問をします。

28 sql  history  coding-standards 

ソフトウェア開発者として、私は小さな自家製アプリから中規模のエンタープライズアプリケーションに至るまでのプロジェクトに取り組んできました。ほとんどすべてのプロジェクトで、データベースを使用したか、最初から使用しないことを選択したことを後悔しました。 今、私はデータベースと一般的なアプリケーションでのそれらの使用についていくつかのことを疑問に思っています： Windows自体が「中央」のSQLデータベースを使用しないのはなぜですか？例えば： エラー報告データは多数のファイルに保存されますが、 Windows Updateはすべてをフラットファイルに保存しますが、 アイコンキャッシュは、SQLなどを介してアクセスされていないように見える非常に奇妙な単一のファイルに格納されます。 多くの大規模なアプリケーションがデータベースの使用を避けるのはなぜですか？たとえば、Microsoft Outlookは、.pstファイル用の独自の形式を持ち、レジストリにデータを保存することにより、車輪を再発明する代わりに、実際のデータベースを使用することで得られませんか？ データベースが全体的な複雑さとわずかなパフォーマンス損失の追加レイヤーを追加する場合、ほとんどの場合、特に大きなバイナリではなく小さな組織化されたデータチャンクのストレージに関して、コードを単純化するという大きな利点の代価ですストリーム。では、実際にデータベースを実際に使用している製品が非常に少ないのはなぜですか？おそらく、実際にSqliteデータベースを使用するアプリケーションは、FirefoxとMicrosoft Exchangeだけでしょう（ただし、最後のアプリケーションはデスクトップアプリケーションではありません）。 また、Microsoft OfficeやMicrosoft Expressionなどの一連のアプリケーションは、統合されたSQLデータベースを持ち、アプリケーションの展開、データの更新/アップグレード、それらのアプリケーション間でのデータの共有、バックアップの作成を容易にすることから恩恵を受けませんなど。

28 sql 

私は差がある知っているINNER JOINとFULL OUTER JOIN2つの違いは、次のされているもの、私はそれを見ることができますが、JOIN ... ON...そしてINNER JOIN...ON...、まだ、まだJOIN...ON...対FULL OUTER JOIN...ON... 理由はJOIN、SOに投稿されているクエリを混乱させるだけだと思うので、ここに質問へのリンクがあります。 それでは基本的に、実際の集合演算自体の構文上の違いは何ですか？ ありがとうございました、

27 sql  sql-server 

少なくともSQLでは、データベーステーブル名は単数形である必要があるという、かなり確立された規則です。この質問と議論をSELECT * FROM user;参照してください。 また、RESTful APIリソース名は複数にする必要があるという確立された規則です。GET /users/123そして、これをPOST /users見てください。 最も単純なデータベースベースのAPIでは、URLのリソースの名前はテーブルになり、URLのデータ要素と要求/応答本文はDBの列に直接マップされます。概念的には、この理論的なAPIを介してデータを操作することと、SQLを介して直接操作することとの間に違いはありません。そして、そのため、間の命名規則の違いuserとはusers私には意味がありません。 概念的に、REST APIとSQLが同じことをしているときに、複数形の違いをどのように正当化できますか？

27 rest  api  sql  conventions  naming-standards 

これは少し自由な質問ですが、インライン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 

StackOverflowの上の最近の問題は、主キーの不変性についての議論を引き起こしました。主キーは不変でなければならないというのは一種のルールだと思っていました。いつか主キーが更新される可能性がある場合は、代理キーを使用する必要があると考えました。ただし、これはSQL標準には含まれておらず、一部のRDBMSの「カスケード更新」機能により、主キーを変更できます。 だから私の質問は次のとおりです。変更される可能性がある主キーを持つことは依然として悪い習慣ですか？可変の主キーを持つことの短所がある場合、それは何ですか？

26 database-development  sql 

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

26 sql  database-design  optimization  ssd 

それは、パフォーマンスと最適なリソース使用率に来るときよりよいアプローチは何である：それだけが必要なときに必要な正確な情報を入手するために複数回のAJAXを介してデータベースにアクセスする、またはすべての情報保持するオブジェクト取得するために、一回のアクセスを実行する可能性が必要となることを、すべてが実際に必要なわけではないという高い確率で？ 実際のクエリをベンチマークする方法は知っていますが、何千人ものユーザーがデータベースに同時にアクセスしているときのデータベースパフォーマンスに関して、接続プーリングがどのように作用するかをテストする方法はわかりません。

25 performance  sql 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 人気のあるSOの投稿によると、テーブル名にプレフィックスを付けることは悪い習慣と見なされています。私の会社では、すべての列の前にテーブル名が付いています。これは読みにくいです。理由は定かではありませんが、この命名は実際には会社の標準です。命名規則に我慢はできませんが、その根拠を裏付けるドキュメントはありません。 私が知っているのは、AdventureWorksを読む方がずっと簡単だということだけです。で、この私達の会社DBは、テーブルが表示され、人とそれは、列の名前を指定できます。 Person_First_Name または Person_Person_First_Name（おそらく、2xの人を見る理由を聞かないでください） 列名に接頭辞を付けるのはなぜ悪い習慣と見なされるのですか？アンダースコアはSQLでも悪と見なされますか？ 注：Pro SQL Server 2008-Relation Databaseの設計と実装を所有しています。その本への参照は大歓迎です。

25 sql 

リレーショナルデータベースプログラマーとして（ほとんどの場合）、リレーショナルデータベースがどのようにスケールしないか、MongoDBなどのNoSQLソリューションがどのようにスケールするかについての記事を読みました。これまでに開発したデータベースのほとんどは小規模から中規模であったため、インデックス作成、クエリの最適化、またはスキーマの再設計によって解決されなかった問題は一度もありませんでした。 MySQLはどのようなサイズに苦しんでいると予想されますか。何行ですか？ （これはアプリケーションと保存されるデータの種類に依存することを知っています。基本的には遺伝学データベースだったので、3つまたは4つのルックアップテーブルを持つ1つのメインテーブルがあります。メインテーブルには、他のもの、染色体参照、および位置座標。おそらく、そこに保存されているものを確認するために、染色体上の2つのポーション間の多くのエントリを照会されます。

24 database  sql  nosql  scalability 

FlaskやDjangoなどの多くのWebフレームワークは、デフォルトのデータベースとしてSQLiteを使用します。 SQLiteはPythonに含まれており、管理オーバーヘッドが非常に低いため、魅力的です。 ただし、トラフィックの多い公共の本番サイトのほとんどは、mySQL、Oracle、またはpostgresqlなどのより重いデータベースを使用しています。 質問： 仮定： サイトのトラフィックは中程度であり、データベースへの同時読み取り/書き込みアクセスが発生します SQLite書き込みロックでSQLAlchemyを使用します（ただし、このコメントは少し緊張しますが） データベースにはおそらく60,000レコードが含まれます データ構造は、より重いデータベースにある高度な機能を必要としません 中程度のトラフィックの社内企業ツールとして機能するWebサイトで、SQLiteの同時実行に対して説得力のある事例はありますか？もしそうなら、どのような条件がSQLiteに並行性の問題を引き起こしますか？ 一般的な恐怖/根拠のない指差しではなく、既知の特定の根本原因を探しています。

23 sql  frameworks  scalability  web-framework  sqlite