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

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

11
データベース内のテーブル間のリレーションを定義する必要がありますか、それともコードで定義する必要がありますか?
私の経験では、過去に読んだプロジェクトの多くは、データベースにリレーションシップ定義を持たず、代わりにソースコードでのみ定義していました。だから私は、データベースとソースコード内のテーブル間の関係を定義することの利点/欠点は何なのかと思っていますか?より広範な質問は、カスケード、トリガー、手順などの現代のデータベースの他の高度な機能に関するものです...私の考えにはいくつかのポイントがあります。 データベース内: 設計からの正しいデータ。無効なデータを引き起こす可能性のあるアプリケーションエラーを防ぎます。 アプリケーションがデータの整合性をチェックするためにより多くのクエリを作成する必要があるため、データを挿入/更新する際のアプリケーションへのネットワークラウンドトリップを削減します。 ソースコード内: より柔軟。 複数のデータベースにスケーリングする場合は、リレーションがクロスデータベースになることがあるため、より良いです。 データの整合性をさらに制御します。データベースは、アプリケーションがデータを変更するたびに確認する必要はありません(複雑さはO(n)またはO(n log n)(?)です)。代わりに、アプリケーションに委任されます。また、アプリケーションでデータの整合性を処理すると、データベースを使用するよりも詳細なエラーメッセージが表示されると思います。たとえば、APIサーバーを作成するときに、データベースでリレーションを定義すると、何かが(参照されているエンティティが存在しないなど)うまくいかない場合、メッセージとともにSQL例外を受け取ります。簡単な方法は、「内部サーバーエラー」が発生したことをクライアントに500で返すことであり、クライアントは何が問題なのかわかりません。または、サーバーはメッセージを解析して何が間違っているのかを判断できます。これはmyい、エラーが発生しやすい方法です。アプリケーションにこれを処理させると、 他に何かありますか? 編集:Kilianが指摘しているように、パフォーマンスとデータの整合性についての私の論点は非常に間違っています。そこで、自分のポイントを修正するために編集しました。データベースで処理できるようにすることは、より効率的で堅牢なアプローチになることを完全に理解しています。更新された質問を確認して、それについて考えてください。 編集:みんなありがとう。私が受け取った答えはすべて、制約/関係をデータベースで定義する必要があることを指摘しています。:)。もう1つ質問がありますが、この質問の範囲外であるため、別の質問として投稿しました:APIサーバーのデータベースエラーを処理します。いくつかの洞察を残してください。

12
リレーショナルデータベースがネストされた形式で情報を返すことをサポートしないのはなぜですか?
ブログを構築していて、投稿やコメントが必要だとします。そこで、自動インクリメント整数「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 

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

4
多くのデザインがRDBMSの正規化を無視するのはなぜですか?
この投稿を改善したいですか?引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 意思決定段階では、正規化が最初の考慮事項ではないという多くの設計を見ました。 多くの場合、これらの設計には30を超える列が含まれており、主なアプローチは「すべてを同じ場所に置く」ことでした 私が覚えていることによると、正規化は最初の最も重要なことの1つです。 編集: 優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか?正規化を念頭に置いて設計を開始することに対する議論は何ですか?

4
パラメータ化されていないクエリにエラーを返させないのはなぜですか?
SQLインジェクションは非常に深刻なセキュリティの問題です。その大部分は間違いを犯しやすいためです。ユーザー入力を組み込んだクエリを作成するための明確で直感的な方法では脆弱性が残り、それを緩和する正しい方法ではパラメーター化について知る必要があります最初にクエリとSQLインジェクション。 これを修正する明白な方法は、明白な(しかし間違った)オプションをシャットダウンすることだと思われます:パラメータの代わりにハードコードされた値をWHERE句で使用する受信したクエリが素敵で説明的なものを返すようにデータベースエンジンを修正します代わりにパラメータを使用するよう指示するエラーメッセージ。これには、管理ツールからのアドホッククエリなどを簡単に実行できるように、オプトアウトオプションが必要になることは明らかですが、デフォルトで有効にする必要があります。 これを行うと、SQLインジェクションがほぼ一晩中停止しますが、私が知る限り、実際にこれを行うRDBMSはありません。そうでない理由はありますか?
22 security  sql  rdbms 

3
オブジェクト指向データベースがリレーショナルデータベースと同じくらい使用されないのはなぜですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 多くのリレーショナルデータベース管理システム(RDBMS)に遭遇しました。しかし最近、休止状態を使用したため、オブジェクト指向データベースの方が人気がないのではないかと思い始めました。 JavaやC#などのオブジェクト指向言語が非常に人気がある場合、オブジェクト指向データベース管理システム(OODBMS)も人気がないのはなぜですか?

10
RDBMSが結合されたテーブルをネストされた形式で返さないのはなぜですか?
たとえば、ユーザーとそのすべての電話番号とメールアドレスを取得したいとします。電話番号とメールは別々のテーブルに保存されます。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 

7
代理キーをユーザーに公開する必要がありますか?
多くの場合、自然キーを持たないテーブルでは、ユーザーが一意に生成された識別子を保持できると便利です。テーブルに代理主キーがある場合(そして、そのような場合は必ず期待します)、そのキーをユーザーに公開する必要がありますか、その目的で別のフィールドを使用する必要がありますか? サロゲートキーを公開しない理由の1つは、レコード間の関係を保持する操作を実行できないが、特定の種類の削除/再挿入、1つのデータベースからデータをコピーする多くの方法など、キー値を変更することです他など 代理キーを公開する主な利点は、とにかく持っているフィールドを簡単に使用できることです。 どのような状況で、代理キーをユーザーに直接公開する方がよいでしょうか?

4
これらの特定のテーブルには代理キーが必要ですか?
バックグラウンド このテーブルがあります +-------------------------+ +------------------------+ |Airport | |Country | |-------------------------| |------------------------| |airport_code string (PK) | |country_code string (PK)| |address string | |name string | |name string | +------------------------+ +-------------------------+ +-------------------------+ |Currency | |-------------------------| |currency_code string (PK)| |name string | +-------------------------+ airport_codeは、IATA(国際航空運送協会)の 空港コードです。飛行機で旅行する場合は、荷物タグで確認できます。 country_codeはISO 3166-1 A3標準の国コードです。オリンピックで見ることができます。 currency_codeは、IS0 417標準の3文字の通貨コードです。国際通貨交換の表示板で確認できます。 ご質問 これらの自然なPKは十分ですか? 業界全体で受け入れられているPKにとって十分な世界的に尊敬されている標準を使用していますか? この表には、何があっても代理変数が必要ですか?

5
ORMを使用せず、ストアドプロシージャを好む場合
PetaPoco micro-ORMを使用しています。ORMツールを使用してデータベースを操作するのは確かに非常に簡単で安全ですが、私が嫌いなのは余分なコードだけです。以前はほとんどのコードをデータベース自体に配置し、ストアドプロシージャ、トリガーなど、RDBMSのすべての機能を使用していました。 ストアドプロシージャ/トリガーでORMを使用しない場合、またはその逆の場合を知りたいです。

2
ORDER BY句がない場合、行はどの順序でフェッチされますか?
1人のプログラマが、同じデータベース構造と同じデータを使用する同じアプリケーションを、Oracle 8とOracle 9の2つの異なるデータベースでのみテストおよび比較しています。 アプリは句なしで クエリを実行しますORDER BY。 彼は、ORDER-BY-lessクエリは両方のデータベースで同じ順序で行を返すべきだと主張しています。 ORDER BY句を明示的に指定しない限り、同じ行順序の保証はないことを彼に伝えます。 データベースには同じインデックスとキーがあります。しかし、説明プランでは、データベースの1つではエンジンが結合テーブルの1つのキーを使用しているのに対し、他のデータベースでは別のデータベースのキーを使用していることを示しています。 彼は、2つのDB環境が等しくないことをほのめかしています。これは、統計やRDBMSエンジンなどが異なるためです。元のデータベースのすべてのインデックスを複製できなかったためではありません。 ORDER BY順序が本当に重要な場合は、明示的に条項を提供する必要があると彼に言います。 質問 だから私は彼をよりよく説明できます: ORDER BY句を明示的に指定しない場合、クエリはどの順序で行をフェッチしますか?また、なぜそのクエリは同じ順序で行を返さないのですか?
11 sql  oracle  rdbms 

2
「全代理」をサポートする正規のソースはありますか?
バックグラウンド 「すべて-PK-必須被サロゲート」のアプローチは、中には存在しないコッドのリレーショナル・モデルまたは任意のSQL標準(ANSI、ISOまたは他)。 正規の本もこの制限を回避しているようです。 Oracle独自のデータディクショナリ方式では、一部のテーブルでは自然キーを使用し、他のテーブルでは代理キーを使用します。これらの人々はRDBMSの設計について1つか2つ知っている必要があるので、これについて触れます。 PPDM(Professional Petroleum Data Management Association)は、同じ標準的な本が推奨する次のことを推奨しています。 次の場合は、代理キーを主キーとして使用します。 自然キーやビジネスキーはありません 自然キーまたはビジネスキーが不適切(頻繁に変更) レコードを挿入する時点では、自然キーまたはビジネスキーの値は不明です。 複数列の自然キー(通常はいくつかのFK)が3列を超えるため、結合が冗長になります。 また、自然なキーは不変である必要があると述べている正規のソースを見つけていません。私が見つけたのは、それらが非常にエスタブルである必要があるということです。 これらの人々はRDBMSの設計についてもある程度知っている必要があるため、PPDMについて触れます。 「全代理」アプローチの起源は、いくつかのORMフレームワークからの推奨に由来するようです。 このアプローチでは、多くのビジネス分析を行う必要がなく、SQLコードの保守性と読みやすさを犠牲にして、迅速なデータベースモデリングが可能になるのは事実です。すべてのテーブルを結合する必要があるなどの日常的なタスクを犠牲にして、将来発生する可能性のあるものや発生しない可能性があるもの(自然なPKが変更されたため、RDBMSカスケード更新機能を使用する必要があります)クエリを実行し、データベース間でデータをインポートするためのコードを記述する必要があります。それ以外の点では非常に順調な手順です(PK衝突を回避する必要があり、事前にステージ/同等テーブルを作成する必要があるため)。 他の議論は、整数に基づくインデックスはより高速ですが、それはベンチマークでサポートされなければならないということです。明らかに、長く変化するvarcharはPKには適していません。しかし、短い固定長のvarcharに基づくインデックスは、整数とほぼ同じくらい高速です。 質問 -「all-PK-must-be-surrogates」アプローチをサポートする正規のソースはありますか? -Coddのリレーショナルモデルは新しいリレーショナルモデルに置き換えられましたか?

5
データベース非正規化の利点の予測
私は常に、データベースの正規化の最高の正規形を追求するように教えられ、3NFを達成するためのバーンスタインの合成アルゴリズムを教えられました。これは非常によくできており、一貫性を維持しながらフィールドを変更できることを知って、データベースを正規化するのは良い感じです。 ただし、パフォーマンスが低下する可能性があります。ですから、非正規化時にスピードアップ/スローダウンを予測する方法があるのか​​と思います。このようにして、3NFを特徴とするFDのリストを作成し、可能な限り非正規化することができます。非正規化が多すぎると、スペースと時間が無駄になると思います。たとえば、巨大なブロブが複製されたり、トランザクションを使用して複数のフィールドを更新する必要があるために一貫性を維持することが困難になったりするためです。 概要:3NF FDセットと一連のクエリがある場合、非正規化のスピードアップ/スローダウンを予測するにはどうすればよいですか?論文へのリンクも高く評価されています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.