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

SQLクエリを別の行に分割する必要がありますか？たとえば、私が取り組んでいるプロジェクトでは、1600列を使用するクエリがあります！1600 +タブ文字。次のようなクエリを作成しました。 "SELECT bla , bla2 , bla FROM bla " . "WHERE bla=333 AND bla=2" . "ORDER BY nfdfsd ..."; しかし、彼らは私にそれらを一行に入れるよう要求し、私のスタイルは悪いフォーマットだと言った。なぜそれが悪い習慣ですか？

17 sql  code-formatting 

より速いパフォーマンスとは何ですか？REST APIを作成し、WebアプリでREST APIを使用してデータベースとのすべてのやり取りを行うか、データベースに直接クエリを実行します（つまり、JDBC for Javaなどのデータベースのクエリに使用する一般的なオブジェクトを使用します）？ RESTでの見方： コード内にオブジェクトを作成して、RESTメソッドを呼び出します HTTPメソッドを呼び出す REST API内のコードがデータベースを照会します データベースがデータを返します REST APIコードはデータをJsonにまとめてクライアントに送信します クライアントはJson / XML応答を受け取ります コード内のオブジェクトへの応答をマップする 一方、データベースを直接クエリする場合： データベースをクエリするクエリ文字列でオブジェクトを作成します データベースがデータを返します コード内のオブジェクトへの応答をマップする これは、REST APIの使用が遅くなることを意味しないのでしょうか？たぶんそれはデータベースのタイプ（SQL vs NoSQL）に依存しますか？

16 database  rest  sql 

全員がローカルテーブルと開発テーブルを変更する開発者のチームで作業する場合、どのようにしてすべての変更を同期しますか？誰もがSQLの変更を保持する中央ログファイルですか？テーブルの変更ステートメント、ローカルデータベースを最新バージョンにするために開発者が実行できる個々の.sqlファイルを追跡するWikiページですか？私はこれらのソリューションのいくつかを使用しましたが、うまく機能する優れた堅実なソリューションを一緒に得るために努力していますので、あなたのアイデアに感謝します。

16 management  version-control  sql 

私の知る限り、ほとんどのリレーショナルデータベースはquery、引数としてSQL文字列を受け取る関数を除き、クエリ用のドライバレベルAPIを提供していません。 私はそれができるとしたらどれほど簡単になると思っています： var result = mysql.select('article', {id: 3}) 結合されたテーブルの場合、少し複雑になりますが、それでも可能です。例えば： var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'}); mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID']) よりクリーンなコード、文字列解析のオーバーヘッドなし、インジェクションの問題なし、クエリ要素の再利用の容易化...多くの利点が見られます。 SQLを介したクエリへのアクセスのみを提供するように選択された具体的な理由はありますか？

15 database  sql 

SQL92およびSQL99標準は、DDLコンストラクトを定義しています。すべてのデータベースがこれをサポートしているわけではなく、別の名前を持っているわけでもありません（たとえば、SQL Serverにはユーザー定義型があります）。CREATE DOMAIN これらにより、データベースで使用される制約されたデータ型を定義し、許可された値に関連するルールを簡素化し、強制することができます。このようなデータ型は、列宣言、ストアドプロシージャや関数への入力および出力などで使用できます。 私が知りたいのですが： データベース設計で実際にドメインを使用していますか？ その場合、どの程度ですか？ それらはどれほど有用ですか？ どのような落とし穴に遭遇しましたか？ これらを将来のデータベース開発で使用する可能性を評価しようとしています。

15 sql  sql-domain 

たとえば、ユーザーとそのすべての電話番号とメールアドレスを取得したいとします。電話番号とメールは別々のテーブルに保存されます。1人のユーザーが多くの電話/メールにアクセスします。私はこれを非常に簡単に行うことができます： SELECT * FROM users user LEFT JOIN emails email ON email.user_id=user.id LEFT JOIN phones phone ON phone.user_id=user.id これに関する問題*は、ユーザー名、DOB、お気に入りの色、および各レコード（ユーザーが電話レコードにメールを送信する）についてユーザーテーブルに保存されている他のすべての情報を返し、おそらく帯域幅を消費して速度が低下することです結果をダウン。 ユーザーごとに1つの行を返し、そのレコード内に電子メールのリストと電話のリストがあった方が良いと思いませんか？また、データの操作がはるかに簡単になります。 LINQまたは他のフレームワークを使用してこのような結果を得ることができることは知っていますが、リレーショナルデータベースの基礎となる設計の弱点のようです。 NoSQLを使用してこれを回避することもできますが、中間点はないはずです。 何か不足していますか？これはなぜ存在しないのですか？ *はい、このように設計されています。わかった。なぜ作業が簡単な代替手段がないのか疑問に思っています。SQLは実行中の処理を続けることができますが、キーワードまたは2つを追加して、デカルト積ではなくネストされた形式でデータを返す少しの後処理を行うことができます。 選択したスクリプト言語でこれを実行できることはわかっていますが、SQLサーバーが冗長データを送信するか（以下の例）、またはのような複数のクエリを発行する必要がありますSELECT email FROM emails WHERE user_id IN (/* result of first query */)。 MySQLにこれに似た何かを返させる代わりに： [ { "name": "John Smith", "dob": "1945-05-13", "fav_color": "red", "email": "johnsmith45@gmail.com", }, …

14 design  sql  rdbms 

適切な正規化を行った後でも、テーブルのインデックスを作成する必要がありますか？これはパフォーマンスにどのように影響しますか？適切に正規化した後、何らかの形でパフォーマンスに影響を与えますか？ 主キーと外部キーが既にある場合、通常どの列にインデックスが付けられますか？ データベースを正規化することはすでに効果的であるようです。しかし、索引付けがデータベースに与える影響をスキップしたかもしれません。これは、クエリを使用する場合にのみ有効ですか？これはどのように機能/実行し、データベースを改善しますか？

14 database  sql  indexing  normalization 

私はプロのプログラマーですが、ソフトウェアエンジニアリングの正式なトレーニングを受けたことはありません。私は頻繁にここを訪れているので、可能な限りユニットテストを書く傾向に気づきました。私のソフトウェアがより複雑で洗練されているので、デバッグを支援するための自動化されたテストをお勧めします。 ただし、私の仕事のほとんどは、複雑なSQLを作成してから、何らかの方法で出力を処理することです。たとえば、SQLが正しいデータを返していることを確認するテストをどのように作成しますか？次に、データが制御されていなかった場合（たとえば、サードパーティシステムのデータ）、ダミーデータの連を手書きせずに処理ルーチンを効率的にテストするにはどうすればよいでしょうか。 私が考えることができる最良の解決策は、一緒にほとんどの場合をカバーするデータのビューを作成することです。次に、これらのビューをSQLに結合して、正しいレコードを返しているかどうかを確認し、ビューを手動で処理して、関数などが意図したとおりに動作しているかどうかを確認します。それでも、それは過度で薄汚いようです。特にテストするデータを見つける...

14 database  sql  tdd  test-automation 

ほとんどの言語は、「関係ベース」または「高レベル」の2つに分類されることを学んでいます。私は以前にSQLを使用したことがありませんが、その構文を読むと、機能/関係ベース（Lisp、Haskell）よりも命令的/高レベルの構文のように見えますか？ または、教授の講義ノートの私の解釈が間違っている可能性があります...しかし、SQLは（高レベルではなく）関係ベースの言語の1つとして間違いなくリストされており、関係ベースと機能的...またはおそらく、SQLがリレーショナルデータベースを扱うという事実が機能言語を実装すべき方法にする理由を理解していないのでしょうか？（そして、プログラミング言語を分類するときに「関係ベース」が「機能的」と同等である理由は？） ありがとう：）

14 programming-languages  sql  relational-database 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 SQLのプログラマーの知識をテストするための質問は何ですか？質問に対する答えは何ですか？そして、質問に関連する概念を理解する可能性が高い時間の観点から、正解の欠如は何を意味しますか？ GOOGLED： SQLチャレンジ

14 sql  hiring 

SOに関するSQLの質問に答えるのに多くの時間を費やしています。私はこのilkのクエリに頻繁に出くわします： SELECT * FROM person WHERE birthdate BETWEEN '01/01/2017' AND '01/03/2017' SELECT * FROM person WHERE birthdate BETWEEN '2017-01-01' AND '2017-03-01' SELECT * FROM person WHERE birthdate BETWEEN 'some string' AND 'other string' つまり、指定されたパラメータの文字列から日付への暗黙的な変換（不良）に依存するか、データベースがx、000,000個のデータベース行値を文字列に変換し、文字列比較を実行します（悪い） 私は時々コメントをします。特に、スマートな回答を書くのが高回答ユーザーである場合、私は本当に自分のデータ型でだらしない/文字列を入力するべきではないと思う人 コメントは通常、to_date（Oracle）、str_to_date（MySQL）、convert（SQLSERVER）、または同様のメカニズムを使用して、文字列を明示的に日付に変換した方が良いと思われる形式を取ります。 --oracle SELECT * FROM person WHERE birthdate BETWEEN TO_DATE('20170101', 'YYYYMMDD') AND TO_DATE('20170301', 'YYYYMMDD') --mysql …

13 sql  data-types  date-format 

現在、次のように追跡/履歴テーブルを構造化します。 PrimaryKey-ID OtherTableId-fk fieldName-追跡するフィールドの名前 OldValue NewValue ユーザー名 CreateDateTime したがって、基本的には、別のテーブル履歴を追跡し、変更されたフィールドの列名を新しい値と古い値で保存するテーブルが必要です。私の質問は、誰でもこれに穴を開けることができますか？また、その追跡がテーブルの列名のみがfieldName列に入力されるようにする最も簡単な方法は何ですか？現在、私のオプションは、作成中のサービスに列挙を含めるか、別のステータステーブルを作成してfieldNameをfkにすることです。より良いアイデアはありますか？ 目標の編集：現在、追跡する必要があるフィールドは2つだけです。1つのフィールドはWebページに表示され、履歴が表示されます。もう1つのフィールドには1つの部門のみがアクセスし、クエリ可能なデータベースのビューにアクセスできます。彼らは、この1つのフィールドだけを照会して、フィールドを変更したユーザーと何に関する情報を取得します。これが、テーブルレコード履歴の正確なコピーではなく、データベースフィールドがテーブル列を定義する場所に設定したかった理由です。将来的にフィールドを追加または削除する可能性がある2つのフィールドのみを追跡する必要があります。 ありがとう！

13 database  sql  tracking 

SQLインジェクション攻撃で私が見たすべては、パラメータ化されたクエリ、特にストアドプロシージャのクエリが、このような攻撃から保護する唯一の方法であることを示唆しているようです。私が（暗黒時代に）働いていたとき、主に保守性が低いと見られていたため、ストアドプロシージャは貧弱なプラクティスと見なされていました。テスト可能性が低い。高度な結合; システムを1つのベンダーにロックしました。（この質問は他のいくつかの理由をカバーしています）。 私が働いていたとき、プロジェクトはそのような攻撃の可能性にほとんど気づいていませんでした。さまざまな種類の破損からデータベースを保護するために、さまざまなルールが採用されました。これらのルールは次のように要約できます。 クライアント/アプリケーションは、データベーステーブルに直接アクセスできませんでした。 すべてのテーブルへのすべてのアクセスはビューを介して行われました（ベーステーブルへのすべての更新はトリガーを介して行われました）。 すべてのデータ項目にドメインが指定されていました。 データ項目をNULL可能にすることは許可されませんでした-これは、DBAが時々歯を磨くという意味がありました。しかし、強制されました。 ロールと権限が適切に設定されました-たとえば、ビューのみにデータを変更する権限を与える制限されたロール。 SQLインジェクション攻撃を防ぐために、このような（強制的な）ルールのセット（必ずしもこの特定のセットである必要はありませんが）は、パラメーター化されたクエリの適切な代替手段ですか？そうでない場合は、なぜですか？データベースは、データベース（のみ）固有の手段によって、このような攻撃から保護できますか？ 編集 質問の強調は、受け取った最初の回答に照らして、わずかに変わりました。基本質問は変更されていません。 EDIT2 パラメータ化されたクエリに依存するアプローチは、システムに対する攻撃に対する防御の周辺ステップにすぎないようです。より根本的な防御が望ましいと思われ、特にインジェクション攻撃から防御する場合でも、そのようなクエリへの依存は不要であるか、それほど重要ではないようです。 私の質問に暗示されているアプローチは、データベースの「装甲」に基づいており、それが実行可能なオプションであるかどうかはわかりませんでした。さらなる研究は、そのようなアプローチがあることを示唆しています。このタイプのアプローチへのポインタを提供する以下のソースを見つけました。 http://database-programmer.blogspot.com http://thehelsinkideclaration.blogspot.com これらのソースから取得した主な機能は次のとおりです。 広範なセキュリティデータディクショナリと組み合わせた広範なデータディクショナリ データディクショナリからのトリガー、クエリ、および制約の生成 コードを最小化し、データを最大化する これまでの回答は非常に有用であり、パラメータ化されたクエリを無視することから生じる困難を指摘していますが、最終的には元の質問に回答しません（太字で強調されています）。

13 design  security  sql  sql-injection 

SQL Devがフリーハンドでコードを記述したり、ビジュアルクエリデザイナを使用してクエリを生成したりするかどうかに興味がありました。ほとんどの場合、クエリデザイナーは複雑でないクエリのほとんどを作成できますか？（私は今、SQL Serverを使い始めたばかりのWinForms開発者です）

13 sql  sql-server 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 SQLクエリで散らかったコードのページを見たときにイライラするのは私だけではないはずです。ActiveRecordおよびその他のORMパターンは、プロジェクトで使用される大量のSQLを軽減するのに役立ちますが、複雑なクエリの多くの場合、SQLの使用は避けられないようです。 SQLクエリを他のコードと一緒に（または外部的に）整理して、どこにでも散らばらないようにする方法についての意見を探していますか？1つの明白なアイデアはビューの使用ですが、多くの場合、ビューは複数の大きなインデックス付きテーブルなどを処理する際にパフォーマンスの問題の原因になる可能性があります。 編集1-あなたはすでにモデルレイヤーに分離されていると仮定しています

13 sql  code-formatting