3

私たちは皆、お気に入りのデータベースを持っています。選択したデータベースを客観的に見ると、どのような欠点があり、何を改善できるでしょうか?

ルール:

  • 欠点ごとに 1 つの返信。
  • 制限の簡単な説明とそれに続く;
  • より詳細な説明、より良い方法の説明、または同じ制限がない別のテクノロジの例。

  • あまり使用していないデータベースを否定しないでください。他のテクノロジーに挑戦するのは簡単ですが、偏見ではなく経験から学びたいと考えています。

4

20 に答える 20

5

Oracle データベースは非常に高価です

オラクルはうまくやっていることをやっていますが、ライセンス費用は恐ろしいものです。これは Oracle XE のリリースによって改善されましたが、その制限により、ソリューションの成長が制約されます。

于 2008-09-23T08:00:04.137 に答える
2

データベースPostgreSQL

SQLプロファイラーに欠陥がない

最近の会議で開発者にこれについて尋ねましたが、今では彼らが実装しようとしているものだと理解しています。

于 2008-09-23T09:00:29.687 に答える
2

データベースMicrosoftSQLServer 2005

「挿入または更新」の欠陥の欠如

説明

多くの場合、レコードが存在するかどうかに応じて、テーブルにレコードを挿入または更新する必要があります。そうするための不可分操作がないと、不要なトランザクションが発生します。

これは、MySQLまたはSQLServer2008では発生しません。

于 2008-09-23T08:19:19.237 に答える
2

他のデータベースの自動インクリメントと比較して、Oracle のシーケンスの柔軟性が気に入っていますが、pk 列のデフォルトとして seq.nextval を設定できないことはやや面倒であり、簡単に修正できるはずです。

于 2008-09-23T19:28:43.403 に答える
1

データベースMySQL5.0.x以降

欠陥リングの複製エラーにより、異なるノードでデータの一貫性が失われます

説明

現在直面している本番環境での最も深刻な問題は、MySQLリングでは、リング自体がエラーを生成し、複製を停止することです。

5.xx以降、リング(またはマスター-マスター-レプリケーション)の構築が可能です。データベースを「リング」にチェーンして、データを相互にレプリケートします。すべてのデータベースノードは、他のすべてのノードからすべての変更を取得します。

エラーは自動インクリメントの失敗の背後にあると想定しています。これは通常のレプリケーションからもわかりますが、新しいバージョンでは、エラーログに十分なエラーメッセージがありません。ここでの問題が修正されない限り、MySQLでこの機能を使用しないことを強くお勧めします。

于 2008-09-23T08:56:07.637 に答える
1

データベースMySQLDefectServerは、破損したテーブルで起動します説明 MySQLに破損したテーブルがある場合、書き込み中またはその他の障害によってテーブルが強制終了された場合、非常に正常に起動し、ユーザーは問題が存在しないかのように続行できます
。確かに、ログにいくつかのエラーメッセージが生成されますが、私の経験から、アプリケーションが奇妙な動作をしている理由を理解しようとしている場合、これは役に立ちません。



他のほとんどのデータベースは、起動時にエラーを検出して修復するか、何らかの破損からの起動を拒否します。

于 2008-09-23T08:21:21.403 に答える
1

データベース:Oracle

問題:テーブル、プロシージャ、列などの名前は30文字を超えることはできません。これは腹立たしいです。

問題:slapdashJDBC準拠です。たとえば、ストアドプロシージャは、JDBC準拠の方法ではなく、独自のOUTパラメータタイプの代わりに結果セットを返します。これは、高レベルのJDBC抽象化を使用できないことを意味します。

于 2008-09-28T13:02:32.720 に答える
1

データベースMySQL

一部のテーブルタイプでのみサポートされる欠陥外部キー

説明

十分に言った。これには明らかなメンテナンスの影響があります。

MySQLマニュアルから

外部キーの定義には、次の条件が適用されます。

  • 両方のテーブルはInnoDBテーブルである必要があり、TEMPORARYテーブルであってはなりません。

そしてここに

InnoDB以外のストレージエンジンの場合、MySQLサーバーはCREATETABLEステートメントのFOREIGNKEY構文を解析しますが、それを使用または保存しません。

これは、他の主要なDBでは発生しません。

于 2008-09-23T08:13:10.970 に答える
1

データベースオラクル

問題一時テーブルの定義がプライベートではありません

説明多くのデータベース (Postgres や Sybase など) では、一時テーブルをその場で作成し、それらに挿入し、必要に応じてインデックスを追加し、それらからクエリを実行できます。Oracle には一時テーブルがありますが、一時テーブルの定義はグローバル名前空間に存在します。したがって、一時テーブルは DBA が作成する必要があり、使用したテーブル定義とコードを同期する必要があります。また、2 つのコードで同様の (ただし同一ではない) テーブル定義が必要な場合は、異なる名前を使用する必要があります。これらの違いにより、開発者にとって一時テーブルの利便性が大幅に低下します。

はい、グローバル定義を持つクエリ オプティマイザーの利点を理解しています。しかし、私にとっては利便性の欠如により、Oracle の一時テーブルは事実上役に立たなくなりましたが、Postgres でそれらを非常に集中的に使用しています。

于 2008-09-23T20:45:16.153 に答える
1

データベースMicrosoft SQL Server

欠陥莫大なライセンス費用

説明

SQL Server には優れた機能があり、.NET 開発と非常によく統合されています。問題は、共有データベースから専用データベースにスケールアップする必要がある場合、ライセンス コストが非常に高くなることです。これにより、実際には専用サーバーで実行する必要があるデータベースが、パフォーマンスとセキュリティの問題を抱えた共有サーバーでホストされることになります。

これは、MySQL または PostgreSQL では発生しません。

于 2008-09-23T08:02:48.980 に答える
1

データベースMicrosoft SQL Server 2005

欠陥UI の実装が不十分

説明

SQL Server 管理スタジオは優れたユーザー エクスペリエンスを提供しません。

  • タブの動作がおかしい: 常に正しいタブを探している
  • 64 ビット バージョンでクラッシュし続ける
  • ストアド プロシージャの許可の概要など、以前のバージョンの一部の機能がありません

これは、バージョン 2000 では発生しません。

于 2008-09-23T08:07:45.507 に答える
1

データベースオラクル

長い間、長いデータ型を適切に処理できませんでした

説明

Oracle は 9i (私が信じている) まで long データ型しか持っていませんでした。しかし、そこには大量のコードがあり、それでも long と関連するすべての制限があります。その最大の問題は、各テーブルが 1 つの長い列しか持つことができず、それが列の最後になければならなかったことです。ロングの制限事項の完全なリストについては、こちらを参照してください。

于 2008-09-23T16:19:52.967 に答える
0

データベースOracle

パッケージの助成金の粒度の欠陥

説明

パッケージにのみ権限を付与でき、パッケージ内のストアドプロシージャには権限を付与できません。または、単一のストアドプロシージャにアクセス許可を付与してから、それらをパッケージの外部に配置することもできます。これには、誰がどのストアドプロシージャを使用するかを事前に知っておく必要があり、リファクタリングは非常に困難です。

これはSQLServerでは発生しません。

于 2008-09-23T08:16:01.167 に答える
0

データベースMicrosoftSQLServer 2005

配列型パラメーターの欠陥の欠如

説明

検索で役立ちます。多くの場合、照合する一連の値を渡す必要があります。SQL 2005では、SQLServer内でCLRを使用して回避策を実行できます。有用性を考えると、この機能をすぐに使用できる方が理にかなっています。

これは、SQLServer2008またはOracleでは発生しません。

于 2008-09-23T08:21:33.757 に答える
0

データベース: すべて

欠点 - データベースを設計するときに何をしているかを知ることが重要であるとは考えていなかった人々による貧弱な設計。すべてのデータベースで発生する問題は、機能の欠落によるものよりも、設計の誤りによるものの方がはるかに多くなります。ですから、彼らはすべて、「考えなくても自分の心を読み、最善の解決策を見つけ出す」という機能を欠いていると思います。

于 2010-11-17T20:40:34.513 に答える
0

データベースポストグル

欠陥分析クエリなし

説明

Oracle によって導入された分析クエリは、SQL 2003 標準の一部です。残念ながら、Postgres はまだそれらを実装していません。

于 2008-09-23T16:09:58.263 に答える
0

データベース:PostgreSQL

**問題: ** たとえば、C# 用のコネクタが実際には最新ではなく、高度な機能でクラッシュすることです。

于 2008-09-23T20:48:14.960 に答える
0

PostgreSQL には優れたフェイルオーバー ソリューションがありませんが、それに取り組んでいることは理解しています。

于 2008-09-23T08:00:48.660 に答える
0

任意の SQL DBMS

欠陥: 重複する行

リレーショナル モデルの利点の 1 つは、重複するタプルを使用せずにすべてを表すことです。つまり、キーを持ち、重複しないリレーションを使用します。残念ながら、SQL はそのように構築されていません。これは、データベース開発者の生活を不必要に困難にします。SQL 開発者は、キーのないテーブルを処理し、重複した行を返すクエリをデバッグする必要があります。

于 2010-11-30T00:21:36.030 に答える
0

データベース: Sql コンパクト エディション

欠点: ストアド プロシージャはサポートされていません。

この制限に関係なく、この DB は、特にスマート クライアントまたはモバイル プラットフォームに配布されるアプリケーションのクライアント キャッシュとして使用されます。

于 2008-09-23T08:07:22.263 に答える