データベース管理者

データベースのスキルを向上させ、コミュニティの他の人から学びたいデータベースの専門家向けのQ&A

3
デュアルテーブルから選択する必要があるのはなぜですか？
これは、StackOverflow / dba.stackexchange（SQL Server、MySQL、PostgreSQL、SQLite（WebSQL）など）に表示される可能性が高い主要な関係データベース管理システムで機能します。 select 'abc' abc, 1 def; Oracleでは機能しません。OracleのDUALから選択する必要があるのはなぜですか？SQLのISO / ANSI標準では、SELECTステートメントにFROM句が必要ですか？ 編集： Per Bacon Bitの答えによれば、SQL標準では必須のようです。 名前DUALは、このような誤った名称であるので、私は例えば、テーブルを作成し、ATOMまたはONEという名前をしていたのであれば、現実には、create table one (atom int);... select 'abc' abc, 1 def FROM one;-パフォーマンスの低下はに比べてありますかSELECT .. FROM DUAL？
15 oracle  select 
2
ORDER BYに使用するには、選択したすべての列をインデックスでカバーする必要がありますか？
SOで、誰かが最近インデックスを使用してORDER BYを使用しないのはなぜかと尋ねました。 この状況には、3つの列と1万行からなるMySQLの単純なInnoDBテーブルが含まれていました。列の1つである整数にインデックスが付けられ、OPはその列でソートされたテーブル全体を取得しようとしました。 SELECT * FROM person ORDER BY age 彼はEXPLAIN、このクエリがfilesort（インデックスではなく）で解決されたことを示す出力を添付し、その理由を尋ねました。 インデックスが使用される原因となるヒントに もかかわらず、誰かが（他からのコメント/賛成をサポートして）選択された列がすべてインデックスから読み取られたときにソートにのみ使用されると回答しました（つまり、通常は列に出力）。インデックスを走査してからテーブルからカラムをフェッチすると、ランダムI / Oが発生するという説明が後で与えられました。FORCE INDEX FOR ORDER BY (age) Using indexExtraEXPLAINfilesort これが表示されますが、上のマニュアルの章の顔に飛ぶためにORDER BY最適化だけでなく、満足していることに強い印象伝え、ORDER BYインデックスからすると、確かに（追加のソートを実行することが好ましいが、filesortクイックソートとマージソートの組み合わせで、それゆえ 必要があります下の結合しました;順番にインデックスを歩きながらテーブルをシークする必要があります-したがって、これは完全に理にかなっています）が、次のように述べながら、この「最適化」の申し立てを無視することもできません。Ω(nlog n)O(n) 次のクエリは、インデックスを使用してORDER BYパーツを解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; 私の読書では、これはまさにこの状況の場合です（ただし、明示的なヒントなしにインデックスが使用されていませんでした）。 私の質問は： MySQLがインデックスを使用することを選択するために、選択されたすべての列にインデックスを付ける必要がありますか ある場合、これはどこに文書化されていますか（もしあれば）？ そうでない場合、ここで何が起こっていましたか？
15 mysql  index  innodb  order-by 
3
範囲内の日付ごとに列を返します
表Aを持っているとしましょう：BookingsPerPerson Person_Id ArrivalDate DepartureDate 123456 2012-01-01 2012-01-04 213415 2012-01-02 2012-01-07 ビューで達成する必要があるのは次のとおりです。 Person_Id ArrivalDate DepartureDate Jan-01 Jan-02 Jan-03 Jan-04 Jan-05 Jan-06 Jan-07 123456 2012-01-01 2012-01-04 1 1 1 1 213415 2012-01-02 2012-01-07 1 1 1 1 1 1 システムはイベント用であるため、各ホテルの予約には1〜15日かかりますが、それ以上はかかりません。どんなアイデアでも大歓迎です。
1
PostgreSQLの金融アプリの認証アプローチの選択
最初にいくつかの背景。 LedgerSMBプロジェクトは、PostgreSQLで実行されるオープンソースの財務会計ソフトウェアプロジェクトです。ユーザー定義関数に非常に大量のビジネスロジックを実装します。これらは、プログラムオブジェクトメソッドとデータベースの動作間の主要なマッピングツールとして機能します。現在、認証ユーザーとしてデータベースユーザーを使用します（一部は選択（これにより中央集中型のセキュリティロジックが可能になり、他のツールを記述してユーザーに与えられたアクセス許可を再利用できます））。また、一部は必要に応じて（SQL-Ledgerそのコードベースにセキュリティをレトロフィットするオプションはあまりありませんでした）。 これにより、LDAPからKerberos 5まで、PostgreSQLがアクセスできる合理的な数のシングルサインオンオプションにアクセスできます。パスワードが関係する場所でもPAMを使用できます。また、他のアプリケーションと統合したり、他のクライアントインターフェイスを許可したりするときに、アクセス許可を再利用できます。財務会計アプリケーションにとって、これは正味の勝利のように思えます。 明らかにコストがかかります。Webアプリケーションの場合、サポートできるHTTP認証のタイプは非常に限られています。たとえば、DIGESTは完全に除外されています。BASICが機能し、KRB5を簡単に実装できます（これは1.4でサポートされ、そのまま使用できるようにする予定です）。非常に強力な認証対策は、これを直接適切に管理することはできませんが、おそらく必要に応じてそれらをシムできます（たとえば、ユーザー名と特定のルートCAに一致するcnを持つBASIC +クライアント側SSL証明書）。 同時に、主に開発群衆から、そして時折、アプリケーションはデータベースではなくセキュリティバリアであるべきだと言うdbaからかなりの批判を受けています。私の見解では、セキュリティ境界は小さいほうが一般的に優れており、ビジネスロジックとセキュリティロジックの再利用が一緒になり、同じレベルでセキュリティロジックを再利用せずにビジネスロジックを再利用するのは危険だと思いますプログラムの。 ここで大きなトレードオフがありませんか？私が検討していない落とし穴はありますか？
4
トランザクションでテーブル構造を変更し、エラーが発生した場合にロールバックできますか？
ALTER TABLE実行中のステートメントがいくつかあります。すべてが機能するわけではありません（SQLデータ比較の実行結果です）。それらをいくつかのトランザクションにグループ化し、何か問題が発生した場合はステートメントをロールバックします。 これは可能ですか、それともロールバックできるデータのみですか？
2
SQL Serverに割り当てられるRAMの量を簡単に確認しますか？
SQL Server 2005では、タスクマネージャーを確認し、少なくともSQL Serverに割り当てられているメモリ量を大まかに確認できます。 SQL Server 2008では、SQLServer：Memory Manager / Total Server Memory（KB）perfカウンターが16,732,760を示していても、ワーキングセットまたはコミットサイズが実際に500 MBを超えることはありません。 タスクマネージャで実際にサーバーメモリを表示する設定はありますか？または、SQL Serverでメモリの使用方法を変更した結果ですか
2
ユーザー認証（役割と権利）モジュールの設計
Delphi UIアプリケーションのバックエンドとなるMS SQL Serverデータベースのユーザー認証モジュールをモデル化しようとしています。基本的に、ユーザーが1つのグループにのみ所属するユーザーアカウントが必要です。グループは、「n」個の権利を持つことができます。 また、ユーザーがアプリケーション設定（たとえば、90日ごと）に基づいてパスワードを変更する必要があるため、パスワード履歴をデータベースに追加します。 また、ユーザーがログインおよびログアウトするたびにイベントを記録したいと思います。私はこれを将来の追加イベントに拡張するかもしれません。 以下に、私の最初のクラックを見つけます。これを行うのはこれが初めてなので、改善するための提案があれば教えてください。 役割ベースのセキュリティの追加属性とパスワードルール/有効期限の制約が必要ですか？
7
暗号化フィールドでMySQLデータベースを検索する方法
私がする必要があるとし、特定のテーブルのフィールド暗号化のMySQLのデータベースを。さらに、暗号化したフィールドの一部を検索する必要があります。 とにかくこれらのフィールドをどのように検索しますか？ 各レコードを段階的に復号化することはオプションではありません。数千のレコードが複数あるとします。各レコードを復号化し、各レコードが検索に一致するかどうかを確認するには、時間がかかりすぎます。 更新2012-09-07 新しいアプリケーションを実装しようとしているので、データベーススキーマにさらに詳細を追加しても構いません。さらに、現在稼働中のアプリケーションを拡張する必要があります。しかし、これらのアプリケーションの場合でも、詳細を追加しても問題ありません。 更新2012-09-08 暗号化はこの質問の核です。 一部の回答で提案されているアクセス制限はすでに適用されていますが、データを暗号化するための正式な要件に適合していません。 この正式な要件は、 Payment Card Industry Data Security Standard [PCI]ではありません。
15 mysql 
1
SQL Serverは、述語が相関していることをどのように知っていますか？
：診断しながら、SQL Server 2008 R2のが悪いカーディナリティ推定（シンプルインデックスにもかかわらず、最新の統計情報など）ので、貧弱なクエリ計画を照会し、私はおそらく関連のKBの記事見つけ クエリを実行するとパフォーマンスの低下：FIXをSQL Server 2008またはSQL Server 2008 R2またはSQL Server 2012の相関AND述語を含む KB記事の意味は「相関」によって推測できます。たとえば、述語＃2と述語＃1は、主に同じ行を対象としています。 しかし、SQL Serverがこれらの相関関係をどのように認識しているかはわかりません。テーブルには、両方の述語の列を含む複数列のインデックスが必要ですか？SQLは統計を使用して、ある列の値が別の列と相関しているかどうかを確認しますか？または、他の方法が使用されていますか？ 私はこれを2つの理由で尋ねています： この修正プログラムを使用してどのテーブルとクエリが改善される可能性があるかを判断するには ＃1に影響を与えるためにインデックス作成、統計などで何をすべきかを知るため
2
フラグの配列（ビットマップ/ビット配列）を格納するためのデータ型
テーブルの各レコードにビット配列を保存し、次の操作をサポートする必要があります。 ビットが設定されているかどうかのテスト、およびビットの設定（SQLを使用） ADO 2.8（ADO.NETではない）を使用した値のクエリと設定 インデックス作成（「カバーインデックス」機能を活用するため） この配列に格納されるビットの最大数は固定されていますが、32を超える場合があります。つまり、単純なint列は常に機能するとは限りません。 これまで見てきたことから、私のオプションは次のとおりです。 複数のint列を使用する bigintを使用します（ビット数が64以下である限り機能します） バイナリを使用 ？ 最初のオプションは機能しますが、データにアクセスするコードにかなりのリファクタリングが必要です。2番目のオプションは一時的な救済であり、これまでの検索では、ADOがbigintでうまく機能するかどうかはあまりわかりません。binaryの経験がなく、他のオプションを認識していません。 要件を考慮して、どのデータ型を選択しますか？
3
存在しない場合は、コードによって新しい関数を作成します
データベースにスクリプトで新しい関数を作成したい。スクリプトコードは次のとおりです。 IF Exists(Select * From sys.sysobjects A Where A.name =N'fn_myfunc' and xtype=N'FN') return; CREATE FUNCTION fn_myfunc () returns varchar(10) AS Begin ... End しかし、上記のスクリプトを実行すると、SQL Serverはエラーを返します。 'CREATE FUNCTION' must be the first statement in a query batch.
4
主キーでソート順が指定されているが、SELECTでソートが実行されている
センサーデータをSensorValuesテーブルに格納しています。テーブルと主キーは次のとおりです。 CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.