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

私のt-sqlの先生は、PKカラムに「Id」という名前を付けることは、それ以上の説明なしに悪い習慣と見なされると教えてくれました。 テーブルのPK列に「Id」という名前を付けるのは悪い習慣と見なされるのはなぜですか？

210 sql  naming  tsql 

それは私が聞いたアイデアのほんの一握りの場所です。SQLで純粋に問題を解決しようとすると、特定のレベルの複雑さを超えると、コードで実際に処理する必要があることを多少認めます。 このアイデアの背後にあるロジックは、ほとんどの場合、データベースエンジンが、コードで実行できるよりもタスクを完了するための最も効率的な方法を見つけるのにより良い仕事をするということです。特に、データに対して実行される操作を条件として結果を作成する場合などです。おそらく現代のエンジンでは、クエリのコンパイルされたバージョンを効果的にJITしてキャッシュし、表面上は理にかなっています。 問題は、この方法でデータベースエンジンを活用することが本質的に悪い設計慣行であるかどうか（およびその理由）です。データベース内にすべてのロジックが存在し、ORMを介して単にヒットしている場合、行はさらにぼやけます。

204 design-patterns  sql 

データベースの代わりに、データをJSONにシリアル化し、必要に応じて保存してディスクにロードします。すべてのデータ管理はプログラム自体で行われ、SQLクエリを使用するよりも速くて簡単です。そのため、なぜデータベースが必要なのか理解できませんでした。 データをディスクに保存するだけでなく、データベースを使用する必要があるのはなぜですか？

193 database  sql  mysql  nosql 

私のデータベースでは、id特定の行を一意に検索できるように、作成するすべてのテーブルの名前に整数の主キーを自動的にインクリメントするという習慣になりがちです。 これは悪い考えと考えられますか？この方法で行うことには欠点がありますか？場合によっては、一意の識別子id, profile_id, subscriptionsがどこにあるか、テーブルの外部へのリンクなどの複数のインデックスがあります。idprofile_ididProfile または、そのようなフィールドを追加したくないシナリオはありますか？

191 design  database  sql  normalization 

エンジニアリングの理由はありますか？RDBMSの場合、「YEAR」は「MONTH」よりも具体的であるため、パフォーマンスと関係があるのではないかと思っていました。たとえば、2000年は1年しかありませんが、毎年「1月」これにより、年ごとに何かを簡単にフィルタリング/ソートできるようになります。そのため、年が最初になります。 しかし、それが本当に意味をなすかどうかはわかりません...何か理由はありますか？

118 sql  engineering  rdbms  date-format 

最近、noSQL DBMSについてたくさん読みました。CAP定理、ACIDルール、BASEルール、および基本理論を理解しています。しかし、noSQLがRDBMSよりも簡単にスケーラブルである理由に関するリソースが見つかりませんでした（たとえば、多数のDBサーバーを必要とするシステムの場合）。 制約と外部キーを保持するとリソースにコストがかかり、DBMSが配布されると、はるかに複雑になると思います。しかし、これ以上のものがあると思います。 誰かがnoSQL / SQLがスケーラビリティにどのように影響するか説明してもらえますか？

100 sql  nosql  scalability 

昨日、私は「趣味」のプログラマーと話し合っていました（私自身はプロのプログラマーです）。私たちは彼の仕事のいくつかに出会い、彼は彼のデータベースのすべての列を（実動サーバー/コード上でも）常に照会すると言いました。 私は彼にそうしないように説得しようとしたが、まだそれほど成功していなかった。私の意見では、プログラマーは、「可愛さ」、効率、およびトラフィックのために実際に必要なものだけを照会する必要があります。私の見方に誤りがありますか？

96 database  sql  mysql  bad-code 

私はプロジェクトのコンセプトに合わせてデータベースを設計しようとしており、熱く議論されている問題のように思われました。私はいくつかの記事を読んで、フィールドにIDなどのリストを保存することは決して（またはほとんど決して）大丈夫ではないことを示すいくつかのStack Overflowの回答を読んでいます-すべてのデータはリレーショナルでなければなりません しかし、私が直面している問題は、タスクアサイナーを作成しようとしていることです。ユーザーはタスクを作成し、複数のユーザーに割り当てて、データベースに保存します。 もちろん、これらのタスクを「Person」に個別に保存する場合、1人に0〜100個のタスクを割り当てることができるため、ダミーの「TaskID」列を数十個用意し、それらをマイクロ管理する必要があります。 繰り返しますが、タスクを「タスク」テーブルに保存する場合、ダミーの「PersonID」列を数十個用意し、それらをマイクロ管理する必要があります。これは以前と同じ問題です。 このような問題の場合、何らかの形でIDのリストを保存しても大丈夫ですか、それとも原則を破らずに達成できる別の方法を考えていないだけですか？

94 database  database-design  sql  relational-database 

SQLを次のようなアプリケーションにハードコードするアン​​チパターンと見なされますか？ public List<int> getPersonIDs() { List<int> listPersonIDs = new List<int>(); using (SqlConnection connection = new SqlConnection( ConfigurationManager.ConnectionStrings["Connection"].ConnectionString)) using (SqlCommand command = new SqlCommand()) { command.CommandText = "select id from Person"; command.Connection = connection; connection.Open(); SqlDataReader datareader = command.ExecuteReader(); while (datareader.Read()) { listPersonIDs.Add(Convert.ToInt32(datareader["ID"])); } } return listPersonIDs; } 通常、リポジトリレイヤーなどがありますが、簡単にするために上記のコードでは除外しています。 私は最近、SQLがソースコードで書かれていると不満を言う同僚からいくつかのフィードバックを得ました。理由を尋ねる機会がなかったので、彼は現在2週間（多分それ以上）離れています。私は彼が次のいずれかを意味したと思います： LINQ …

87 c#  sql 

私はこの主題が少し物議を醸すことを知っています、そして、インターネットの周りに浮かんでいる多くの様々な記事/意見があります。残念ながら、それらのほとんどは、その人がNULLと空の文字列の違いを知らないことを前提としています。そのため、結合/集計を使用した驚くべき結果についてのストーリーを伝え、一般にもう少し高度なSQLレッスンを行います。これを行うことで、彼らは絶対に全体のポイントを見逃し、したがって私にとって役に立たない。したがって、この質問とすべての回答が主題を少し前進させることを願っています。 個人情報（名前、生年月日など）を含むテーブルがあり、列の1つがvarchar型の電子メールアドレスであるとします。何らかの理由で、一部の人々は電子メールアドレスを提供したくないかもしれません。このようなデータ（電子メールなし）をテーブルに挿入する場合、2つの選択肢があります。セルをNULLに設定するか、空の文字列（ ''）に設定します。あるソリューションを別のソリューションよりも選択することの技術的な影響をすべて把握しており、どちらのシナリオでも正しいSQLクエリを作成できると仮定します。問題は、両方の値が技術レベルで異なっていても、論理レベルでまったく同じであることです。NULLと ''を見た後、私はただ一つの結論に達しました：その男のメールアドレスがわかりません。どんなに頑張っても NULLまたは空の文字列を使用して電子メールを送信できなかったため、明らかにほとんどのSMTPサーバーは私のロジックに同意します。そのため、値がわからない場合はNULLを使用する傾向があり、空の文字列は悪いことだと考えます。 同僚との激しい議論の後、2つの質問がありました。 不明な値に空の文字列を使用すると、データベースが事実について「嘘をつく」ことになりますか？もっと正確に言うと、何が価値で何がそうでないのかというSQLの考えを使用して、結論が出るかもしれません。しかし、その後、電子メールを送信しようとすると、矛盾した結論に達します。いいえ、電子メールアドレスがないため、@！＃$データベースは嘘をついているはずです。 空の文字列 ''が重要な情報（値と値なし以外）の非常に優れたキャリアになる可能性のある論理的なシナリオはありますか？空の文字列を実際の値やNULLと一緒に使用するのが良い場合があると主張する多くの投稿を見てきましたが、これまでのところ（SQL / DB設計の観点から）論理的なシナリオは見ていません。 PS一部の人々は、個人的な好みの問題であると答えたいと思うでしょう。私は同意しません。私にとって、それは重要な結果を伴う設計上の決定です。だから、これについての意見がいくつかの論理的および/または技術的理由によって裏付けられている答えを見てみたい。

72 design  database  sql  strings  null 

これは学校で私を悩ませたものです。 5年前、私がSQLを学んだとき、最初に必要なフィールドを指定し、次にそれらのフィールドを指定する理由を常に考えていました。 私の考えによると、次のように書く必要があります。 From Employee e Select e.Name それで、なぜ規範は次のように言うのですか？ Select e.Name -- Eeeeek, what does e mean? From Employee e -- Ok, now I know what e is SQLを理解するのに何週間もかかりましたが、その時間の多くは間違った要素の順序によって消費されていたことを知っています。 C＃で書くようなものです。 string name = employee.Name; var employee = this.GetEmployee(); したがって、これには歴史的な理由があると思います。どうして？

67 sql  history  syntax 

私は非常にイライラする必要があるかどうか、または何がわからない。大規模なデータベースに対して300を超えるクエリを独力で構築し、後で見つけられるように命名規則を開発しました。私のオフィスの他の誰もクエリの作成方法を知りませんが、昨日、すべてのクエリの名前が変更されたことを知りました。私は今、物事を見つけるのに非常に苦労しています。 私は責任者と話をしましたが、彼女はすべてを軽視しました。彼女はもっと簡単に見つけられるように名前を変更したと言いました。残念ながら、私はそれらを構築、編集、および保守する方法を知っている唯一の人であり、彼女がそれらを見つける必要がある唯一の理由はクエリをテストすることでした。新しい命名規則はまったく意味をなさないため、開発プロセスで後方への一歩を踏み出したように感じます。 私が理解しようとしているのは： 1）私は過剰反応していますか？ 2）これを処理する最良の方法は何ですか？私はこれを上司に話すのは嫌いですが、昨日同僚と話した後、彼女は何も悪いことをしていないように感じていることをすでに伝えることができます。

63 database  sql  access 

私はリレーショナルデータベースでかなりの作業を行ってきましたが、優れたスキーマ設計の基本概念はかなりよく理解していると思います。私は最近、DBが高給コンサルタントによって設計されたプロジェクトを引き継ぐことを任されました。私の腸の本能-「WTF ??！？」-保証されていますか、それともこの男は私の天才であるかのような天才ですか？ 問題のDBは、従業員からのリクエストを入力するために使用される社内アプリです。そのほんの一部を見るだけで、ユーザーに関する情報と、行われているリクエストに関する情報が得られます。私はこれを次のように設計します： ユーザー表： UserID (primary Key, indexed, no dupes) FirstName LastName Department リクエスト表 RequestID (primary Key, indexed, no dupes) <...> various data fields containing request details UserID -- foreign key associated with User table シンプルでしょ？ コンサルタントは次のように設計しました（サンプルデータを使用）。 UsersTable UserID FirstName LastName 234 John Doe 516 Jane Doe 123 Foo Bar …

61 database  sql  schema 

私の考えでは、SQLインジェクション攻撃は次の方法で防止できます。 入力を慎重にスクリーニング、フィルタリング、エンコードする（SQLへの挿入前） 使用して準備された文 /パラメータ化クエリを それぞれに長所と短所があると思いますが、なぜ＃2が離陸し、インジェクション攻撃を防ぐための事実上の方法であると見なされるようになったのですか？単に安全でエラーが発生しにくいのですか、それとも他の要因がありましたか？ 私が理解しているように、＃1が適切に使用され、すべての警告が処理されれば、＃2と同じくらい効果的です。 サニタイズ、フィルタリング、エンコード 私の側では、サニタイズ、フィルタリング、およびエンコードの意味が混乱していました。この場合、サニタイズとフィルタリングは入力データを変更または破棄する可能性があることを理解していますが、エンコードはデータをそのまま保持しますが、エンコードしますインジェクション攻撃を避けるために適切に。データをエスケープすることは、それをエンコードする方法と考えることができると信じています。 パラメータ化されたクエリとエンコーディングライブラリ parameterized queriesとの概念がencoding libraries相互に交換可能に扱われている答えがあります。私が間違っている場合は修正しますが、私はそれらが異なっているという印象を受けています。 私が理解しているのは、encoding librariesどんなに優れていても、SQL「プログラム」を変更する可能性は常にあるということです。 Parameterized queries 一方、SQLプログラムをRDBMSに送信すると、RDBMSはクエリを最適化し、クエリ実行プランを定義し、使用するインデックスを選択するなどして、RDBMS内の最後のステップとしてデータをプラグインします。自体。 エンコーディングライブラリ data -> (encoding library) | v SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement パラメータ化されたクエリ data | v SQL -> RDBMS (query execution plan defined) -> …

59 security  sql  history  hacking  sql-injection 

1週間、NoSQLデータベースについて学んでいます。 NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。 しかし、多くの場合、NoSQLがリレーショナルデータベースを置き換えることができるかのように記事を書きます。そして、頭を動かせない点があります。 NoSQLデータベースは（多くの場合）キーと値のストアです。 もちろん、（JSON、XMLなどでデータをエンコードすることで）すべてをキーと値のストアに保存することは可能ですが、多くの場合、特定の基準に一致するデータを取得する必要があるという問題がありますユースケース。NoSQLデータベースでは、効果的に検索できるキーは1つだけです。リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。 そのため、NoSQLデータベースは、コンテンツで検索する必要がある永続的なデータには実際には選択できません。または、私は何かを誤解しましたか？ 例： Webショップのユーザーデータを保存する必要があります。 リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。 NoSQLデータベースでは、各ユーザーを自分のIDをキーとして、すべてのデータ（JSONなどでエンコードされた）を値として保存します。 したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者が彼らについて何かを知る必要があります）、リレーショナルデータベースでは簡単に行えますが、NoSQLデータベースではあまり効果的ではありません。すべてのユーザーを取得し、すべてのデータを解析してフィルターします。 私はそれが不可能だとは言いませんが、それははるかにトリッキーになり、NoSQLエントリのデータを検索したい場合はそれほど効果的ではないと思います。 この国に住んでいるすべてのユーザーのキーを格納する国ごとにキーを作成し、この国のキーに保管されているすべてのキーを取得することで特定の国のユーザーを取得できます。しかし、この手法により、複雑なデータセットはさらに複雑になります。SQLデータベースへのクエリほど実装が難しく、効果的ではありません。ですから、本番環境で使用する方法ではないと思います。またはそれは？ そのようなユースケースを処理するために、何かを誤解したり、いくつかの概念やベストプラクティスを見落としたりしたかどうかは、本当にわかりません。たぶん、あなたは私の声明を修正し、私の質問に答えることができます。

51 database  database-design  sql  nosql  relational-database