問題タブ [database]

SQL Server にDATETIMEは、時間要素を含む列があります。

例：

時間の部分を無視して、特定の日のレコードのみを選択する最良の方法は何ですか?

例: (時間の部分と一致せず、行を返さないため、安全ではありません)

注: このサイトは、拾って忘れたメモやテクニックを書き留めることも目的としているため、MSSQL の DATETIME に関する内容はおそらく SQLBOL で最も検索するトピックであるため、この質問に対する私自身の回答を投稿します。

明確化された例を更新して、より具体的にします。

編集申し訳ありませんが、間違った回答 (間違った結果を返す回答) を修正する必要がありました。

@Jorrit: WHERE (date>'20080813' AND date<'20080815')13 番目と 14 番目を返します。

@wearejimbo:閉じますが、葉巻はありません! あなたに授与されるバッジ。2008 年 8 月 14 日 23:59:001 から 23:59:999 に書き込まれたレコードを見逃しました (つまり、真夜中の 1 秒前)。

特定のデータベースの大きさを把握しようとしています（まだ作成されていません）。行数とテーブルがどうなるかはわかっています。そのような理論上のデータベースのサイズを教えてくれるOracleの機能はありますか？使用できる既知の数式はありますか？既存のデータベースのサイズを決定する機能があることは知っていますが、データベースを作成する前に、そのサイズを知りたいと思います。

リレーショナル データベースの設計、パフォーマンスのチューニングなどのベスト プラクティスに関する本/サイト/チュートリアルを探しています。この種のリソースを見つけるのは少し難しいことがわかりました。「これが正規化で、ここが ER ダイアグラムです」という言葉はたくさんありますが、実際の例はあまりありません。誰にもアイデアはありますか？

私は現在、小さな CRUD アプリケーションを設計しています。彼らのデータベースは非常に混乱しており、今後 6 か月から 1 年の間に頻繁に変更されます。私のデータレイヤーに何をお勧めしますか:

1) ORM (もしそうなら、どれ?)

2) Linq2Sql

3) ストアド プロシージャ

4) パラメータ化されたクエリ

テーブルを置き換えたり、列を頻繁に追加/削除したりできる、十分に動的な（高速かつ簡単な）ソリューションが本当に必要です。

注: 私は ORM の経験があまりなく (SubSonic は少しだけ)、一般的にストアド プロシージャを使用する傾向があるため、おそらくそれが適しているでしょう。上記の状況が許されるのであれば、Ling2Sql または NHibernate を学びたいと思っています。

例：where句を追加するのを忘れたため、customerテーブルのすべての行を更新します。

1. それを実現し、同僚や顧客に報告するのはどのようなものでしたか？
2. 学んだ教訓は何でしたか？

文字列に対して検索するクエリがあります。

さて、これは問題なく動作しますが、うまくスケーリングできず、最適化する必要があります。生成されたビューの作成などのオプションを見つけましたが、インデックスを使用したより簡単なソリューションを望んでいました。

DB2 を使用しており、実際には index で式を使用したいのですが、このオプションは z/OS でしか使用できないようですが、Linux を実行しています。とにかく式インデックスを試しました：

しかしもちろん、それは UPPER(名前) で詰まります。

既存のクエリを再構築して新しく生成されたビューを使用したり、既存の列を変更したり、その他のそのような侵入的な変更を行う必要がないように、この方法でインデックスまたは同様のものを作成できる別の方法はありますか?

編集：私は他のデータベースの解決策を聞くことにオープンです...それはDB2に引き継がれるかもしれません...

正規化された注文データの大規模なデータベースがあり、レポートのクエリが非常に遅くなっています。レポートで使用するクエリの多くは、5つまたは6つのテーブルを結合し、数万または数十万の行を調べる必要があります。

クエリはたくさんあり、そのほとんどはサーバーの負荷を減らして速度を上げるために可能な限り最適化されています。非正規化された形式でデータのコピーを保持し始める時が来たと思います。

アプローチに関するアイデアはありますか？いくつかの最悪のクエリから始めて、そこから進む必要がありますか？

複数のクライアント用に設計されたデータベース中心のアプリケーションでは、すべてのクライアントに単一のデータベースを使用する方が「良い」と常に思っていました。つまり、レコードを適切なインデックスとキーに関連付けます。Stack Overflowポッドキャストを聞いていると、JoelがFogBugzがクライアントごとに1つのデータベースを使用していると聞いた（したがって、1000のクライアントがある場合は1000のデータベースがある）。このアーキテクチャを使用する利点は何ですか？

一部のプロジェクトでは、クライアントがすべてのデータに直接アクセスする必要があることを理解しています。このようなアプリケーションでは、各クライアントが独自のデータベースを必要とすることは明らかです。ただし、クライアントがデータベースに直接アクセスする必要がないプロジェクトの場合、クライアントごとに1つのデータベースを使用することに利点はありますか？柔軟性の観点から、テーブルの単一のコピーで単一のデータベースを使用する方がはるかに簡単なようです。新しい機能の追加、レポートの作成、および管理が簡単になります。

Joel（経験豊富な開発者）が彼のソフトウェアは別のアプローチを使用していると言うのを聞くまで、私は「すべてのクライアントに1つのデータベース」の方法にかなり自信を持っていました。

多数のレコードがあるとデータベースの速度が低下すると言われていると聞きましたが、特に適切なインデックスとキーが使用されている場合は、メリットのあるリレーショナルデータベースでその問題が発生することはありません。

どんな入力でも大歓迎です！

私の現在の開発プロジェクトには 2 つの側面があります。まず、外部ユーザーがさまざまな目的で情報を送信および更新できる公開 Web サイトがあります。この情報は、コロ施設のローカル SQL Server に保存されます。

2 番目の側面は、従業員が同じレコードを (概念的に) 管理し、ステータスの更新、承認などを提供するために使用する内部アプリケーションです。このアプリケーションは、独自のローカル SQL Server データベースを使用して、企業のファイアウォール内でホストされます。

2 つのネットワークはハードウェア VPN ソリューションによって接続されています。これはまともですが、明らかに世界で最も高速なものではありません.

2 つのデータベースは類似しており、同じテーブルの多くを共有していますが、100% 同じではありません。両側のテーブルの多くは、内部または外部アプリケーションに非常に固有のものです。

問題は、ユーザーが自分の情報を更新したり、公開 Web サイトで記録を送信したりするとき、そのデータを内部アプリケーションのデータベースに転送して、内部スタッフが管理できるようにするにはどうすればよいかということです。またその逆も同様です... スタッフが行った更新を Web サイトに戻すにはどうすればよいですか?

これらの更新がより「リアルタイム」に行われるほど、より良いことに言及する価値があります。すぐに実行する必要はありませんが、適度に高速です。

これまでのところ、次のタイプのアプローチを使用することを考えてきました。

1. 双方向レプリケーション
2. 変更が行われたときに (リアルタイムで) 同期するためのコードを含む、両側の Web サービス インターフェイス。
3. 変更を非同期的に同期するためのコードを含む両側の Web サービス インターフェイス (キューイング メカニズムを使用)。

何かアドバイス？以前にこの問題に遭遇した人はいますか? あなたにとってうまくいく解決策を思いつきましたか？

自動リンクとは、ページ コンテンツにインライン化された wiki リンクが、ページへのハイパーリンク (存在する場合) または作成リンク (ページが存在しない場合) に生成されるプロセスです。

私が使用しているパーサーでは、これは 2 段階のプロセスです。まず、ページ コンテンツが解析され、ソース マークアップから Wiki ページへのすべてのリンクが抽出されます。次に、最終的な HTML マークアップが生成される前に、既存のページの配列をパーサーに戻します。

このプロセスを処理する最善の方法は何ですか? 毎回ページ タイトルのインデックスを抽出するのではなく、サイト上のすべてのページのキャッシュ リストを保持する必要があるようです。それとも、各リンクを個別にチェックして、存在するかどうかを確認する方がよいでしょうか? リストがキャッシュされていない場合、これにより多くのデータベース ルックアップが発生する可能性があります。これは、何千ページもある大規模な Wiki サイトでも実行可能でしょうか?