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

私はSQLに真剣な経験はなく、LINQの代わりにSQLを書くことさえ嫌いです。ORMには十分満足しています。 雇用主とセクターの観点から、SQLを知ることは重要ですか？習得する必要がありますか？ORMフレームワークよりも純粋なSQLを好む企業は、プログラミングの世界で「恐竜」ですか？

50 sql  orm  entity-framework 

ブログを構築していて、投稿やコメントが必要だとします。そこで、自動インクリメント整数「id」列を持つ「posts」テーブルと、外部キー「post_id」を持つ「comments」テーブルの2つのテーブルを作成します。 次に、おそらく最も一般的なクエリを実行します。クエリとは、投稿とそのコメントをすべて取得することです。リレーショナルデータベースはかなり新しいので、私にとって最も明白なアプローチは、次のようなクエリを作成することです。 SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments FROM posts WHERE id = 7 これにより、必要な投稿のIDとコンテンツ、および配列（JSONで使用するようなネストされた表現）にきちんとパッケージ化されたすべての関連するコメント行が得られます。もちろん、SQLおよびリレーショナルデータベースはこのようには機能せず、最も近い方法は、「投稿」と「コメント」の間の結合を行うことです。これにより、多くの不必要なデータの重複が返されます（同じ投稿情報が繰り返されます）すべての行で）、つまり、データベースをまとめて処理するためと、ORMですべてを解析して元に戻すための両方の処理時間が費やされます。 ORMに投稿のコメントを熱心に読み込むように指示した場合でも、最善の方法は、投稿に対する1つのクエリをディスパッチし、次にすべてのコメントを取得する2番目のクエリをディスパッチしてからクライアント側にまとめることです。また非効率的です。 リレーショナルデータベースは実証済みのテクノロジーである（地獄、私よりも古い）こと、そして何十年にもわたって膨大な量の研究が行われていることを理解しています。そして、それらには本当に正当な理由があると確信しています（そしてSQL標準）は、そのように機能するように設計されていますが、上記で説明したアプローチが不可能な理由はわかりません。私は、レコード間の最も基本的な関係の1つを実装する最も単純で明白な方法であるように思えます。リレーショナルデータベースがこのようなものを提供しないのはなぜですか？ （免責事項：私は主にRailsとNoSQLデータストアを使用してwebappを書いていますが、最近Postgresを試しました。実際にそれが大好きです。リレーショナルデータベースを攻撃するつもりはありません。ただ困惑しています。） Railsアプリを最適化する方法や、特定のデータベースでこの問題を回避する方法を尋ねるのではありません。私は直感に反し、無駄に思えるのに、なぜSQL標準がこのように機能するのかを尋ねています。SQLの元の設計者が結果をこのようにしたかったという歴史的な理由がいくつかあるに違いありません。

46 database  sql  rdbms  query 

セミオープン（またはハーフオープン、ハーフクローズ、ハーフバウンド）間隔（[a,b)、x間隔iffに属するa <= x < b）は、多くの便利なプロパティがあるため、プログラミングではかなり一般的です。 誰もがSQL BETWEENが閉じた間隔（[a,b]）を使用する理由を説明する根拠を提供できますか？これは特にです。日付に不便。なぜBETWEENこんなふうに振る舞うのでしょうか？

45 sql 

次のSQLクエリは同じです。 SELECT column1, column2 FROM table1, table2 WHERE table1.id = table2.id; SELECT column1, column2 FROM table1 JOIN table2 ON table1.id = table2.id; そして確かに、私が試したすべてのDBMSで同じクエリプランが得られます。 しかし、時々、一方が他方よりも間違いなく優れているという意見を読んだり聞いたりします。当然、これらの主張は説明によって実証されることはありません。 私が働いている場所では、2番目のバージョンは他の開発者の大多数に好まれているようです。そのため、驚きを最小限に抑えるために、このスタイルに向かう傾向もあります。しかし、私の心の中で、私は本当に最初のものを考えています（それが最初にそれを学んだ方法だからです）。 これらの形式の1つは、他の形式よりも客観的に優れていますか？そうでない場合、一方を他方よりも使用する理由は何でしょうか？

45 sql  coding-style 

私は今、SQLデータベースを使用していますが、これは常に興味をそそりますが、Google検索はあまり現れません。なぜ厳密なデータ型なのでしょうか？ たとえば、バイナリデータとプレーンテキストデータの区別が重要であるなど、いくつかの異なるデータ型がある理由を理解しています。バイナリデータの1と0をプレーンテキストとして保存するのではなく、バイナリデータを独自の形式で保存する方が効率的であることを理解しています。 しかし、私が理解していないのは、非常に多くの異なるデータ型を持つことの利点です： なぜmediumtext、longtextとtext？ なぜdecimal、floatとint？ 等 「この列のエントリにはプレーンテキストデータが256バイトしかありません」とデータベースに伝えることの利点は何ですか。または「この列には最大16,777,215バイトのテキストエントリを含めることができますか？」 パフォーマンス上のメリットはありますか？もしそうなら、手作業の前にエントリーのサイズを知ることがパフォーマンスに役立つのはなぜですか？それとも、まったく別のものですか？

44 database  sql  relational-database  data-types 

質問はそのタイトルから明確でなければなりません。たとえば、Apacheは、使用されている規模に関係なく、RDBMSではなくファイルにアクセスログとエラーログを保存します。 RDMSの場合はSQLクエリを記述するだけで機能しますが、ファイルの場合は特定の形式を決定し、正規表現を記述するか、パーサーとして操作する必要があります。そして、細心の注意を払わないと、特定の状況で失敗することさえあります。 しかし、誰もがログを維持するためにファイルシステムを好むようです。私はこれらの方法のいずれにも偏っていませんが、なぜこのように実践されているのか知りたいです。それはスピードや保守性などですか？

44 sql  history  rdbms  file-systems  rdms 

私はドメイン駆動設計（DDD）に飛び込んでいますが、さらに深く掘り下げていくと、得られないことがいくつかあります。私が理解しているように、主なポイントは、ドメインロジック（ビジネスロジック）をインフラストラクチャ（DB、ファイルシステムなど）から分離することです。 私が疑問に思っているのは、マテリアルリソース計算クエリのような非常に複雑なクエリがある場合、どうなりますか？この種のクエリでは、SQLが設計された種類の重いセット操作を操作します。ドメインレイヤー内でこれらの計算を行い、その中の多くのセットを操作することは、SQLテクノロジーを破棄するようなものです。 DDDパターンでは、ドメインレイヤーを変更せずにMongoDBにSQL Serverなどの同じ機能がないことを認識せずにインフラストラクチャを変更できるため、インフラストラクチャでこれらの計算を行うこともできません。 それはDDDパターンの落とし穴ですか？

44 domain-driven-design  database-design  sql  database-development 

私が元々SQLについて学んでいたとき、私はいつも言われました。本当に必要な場合にのみトリガーを使用し、可能であれば代わりにストアドプロシージャを使用することを選択します。 残念ながら当時（数年前）、私は今ほどファンダメンタルズに興味がなく、その理由を尋ねることはありませんでした。 これに関するコミュニティの意見は何ですか？誰かの個人的な好みなのか、それとも正当な理由がない限り、トリガーは（カーソルのように）避けるべきなのか。

43 sql 

私は、多くの（少なくとも3-4）テーブルにわたる結合といくつかのネストされた条件を含む複雑なSQLクエリを書くことは非常に難しいと思っています。書くように求められているクエリは、いくつかの文で簡単に説明できますが、完了するためには、途方もない量のコードが必要になる場合があります。私はこれらのクエリを書くために一時的なビューを頻繁に使用していることに気付いています。これらの複雑なクエリを簡単にするために使用できるヒントを教えてください。より具体的には、これらのクエリを、実際にSQLコードを記述するために使用する必要があるステップに分割するにはどうすればよいですか？ 私が書くように頼まれているSQLはデータベースコースの宿題の一部であることに注意してください。したがって、私のために仕事をするソフトウェアは欲しくありません。私が書いているコードを実際に理解したい。 技術的な詳細： データベースは、ローカルマシンで実行されているPostgreSQLサーバーでホストされます。 データベースは非常に小さく、7つ以下のテーブルがあり、最大のテーブルは約50行未満です。 SQLクエリは、LibreOffice Baseを介して、変更されずにサーバーに渡されます。

42 sql  tips  query 

典型的なWebアプリケーションでは、日付は強く型付けされたデータベースレイヤーから取得されます（たとえば、c＃ではSystem.StringではなくSystem.DateTimeとして）。 日付を文字列として表現する必要がある場合（ページに表示するなど）、DateTimeから文字列への変換はプレゼンテーション層で行われます。 どうしてこれなの？DateTimeをデータベース層の文字列に変換するのはなぜ悪いことですか？ チャットでの激しい議論や、これを始めた最初の質問も見てください。

41 database  sql  formatting 

新しい開発者が長い関数を書くことは誰もが知っています。進歩するにつれて、コードを小さな断片に分割するのが上手になり、経験がそうすることの価値を教えてくれます。 SQLを入力します。はい、SQLのコードについての考え方は、手順についてのコードについての考え方とは異なりますが、この原則は同じように思えます。 次の形式のクエリがあるとします。 select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4 いくつかのIDや日付などを使用する これらのサブクエリはそれ自体が複雑であり、独自のサブクエリを含む場合があります。他のプログラミングコンテキストでは、複雑なサブクエリ1〜4のロジックは、それらすべてを結合する親クエリに一致するとは考えられません。私が手続き型コードを書いている場合にそれらが関数であるように、それらのサブクエリはビューとして定義されるべきであるように非常に簡単です。 では、なぜ一般的な慣行ではないのでしょうか？なぜこれらの長いモノリシックSQLクエリを頻繁に書くのですか？なぜ手続き型プログラミングが広範な関数の使用を奨励するように、SQLが広範なビューの使用を奨励しないのか。（多くのエンタープライズ環境では、ビューの作成は簡単にできるものではありません。要求と承認が必要です。他のタイプのプログラマーが関数を作成するたびに要求を送信しなければならないと想像してください！） 私は3つの可能な答えを考えました： これはすでに一般的であり、私は経験の浅い人々と仕事をしています 経験豊富なプログラマーは、手続き型コードを使用してハードデータ処理の問題を解決することを好むため、複雑なSQLを作成しません 他の何か

39 refactoring  sql  enterprise-development 

アプリケーション内の地理的な場所を表す、基礎となるデータモデルの設計は、2つの明確なオプション（またはそれ以上？）を提案します。 自己参照parent_id列ukを持つ1つのテーブル-ロンドン（ロンドンの親ID =英国ID） 外部キーを使用する1対多の関係を持つ2つのテーブル。 私の好みは、必要な数のサブリージョンに簡単に拡張できるため、1つの自己参照テーブルです。 一般に、人々は自己参照テーブルから離れますか、それともA-OKですか？

37 sql  database-design 

T-SQLを学んでいます。私が見た例から、varchar()セルにテキストを挿入するために、挿入する文字列だけを書くことができますが、nvarchar()セルの場合、すべての例は文字列の前に文字Nを付けます。 nvarchar()行があるテーブルで次のクエリを試しましたが、正常に機能するため、プレフィックスNは必要ありません。 insert into [TableName] values ('Hello', 'World') 私が見たすべての例で、文字列の先頭にNが付いているのはなぜですか？ このプレフィックスを使用することの長所と短所は何ですか？

34 sql  sql-server  character-encoding  unicode 

ではSQLを学びハード・ウェイ（エクササイズ6） 、作者では、以下のクエリ： SELECT pet.id, pet.name, pet.age, pet.dead FROM pet, person_pet, person WHERE pet.id = person_pet.pet_id AND person_pet.person_id = person.id AND person.first_name = "Zed"; その後、次のように言います： 実際には、これらの種類のクエリを機能させる「結合」と呼ばれる他の方法があります。これらの概念はめちゃくちゃ混乱しているので、今のところは避けています。とりあえずこのテーブルの結合方法に固執し、これが何らかの理由で遅いか「低クラス」であることを伝えようとする人々を無視してください。 本当？なぜですか？

32 sql 

SQLは、「SQL」のように/ ˌɛskjuːˈɛl /として正式に発音されます。 ボーリュー、アラン（2009年4月）。メアリーE.トレセラー。編 SQLの学習（第2版）。米国カリフォルニア州セバスタポル：オライリー ISBN 978-0-596-52083-0。 しかし、しばしば「sequel」のように/ ˈsiːkwəl /と発音されますが、この2番目の発音の背後にある歴史は何ですか？

32 sql  history