RDBMSに関する世界観です。データベースの世界観とMySQLの世界観も参照のこと。
OSSデータベースのPostgreSQLとMySQLを比べると、PostgreSQLの方が機能は多いが、MySQLは軽量かつ性能が良い。
オープンソースのSQLサーバ。事実上の標準。MySQLを参照のこと。
オープンソースのSQLサーバ。MySQLのライバル。PostgreSQLを参照のこと。
小規模向けのSQLエンジン。アプリケーションに組み込みで利用出来る。SQLiteを参照のこと。
アプリケーションに埋め込む形式のデータベースのオープンソースなライブラリ。
Wikipedia
ボーランドのInterBaseからオープンソース化されたRDBMS。
Wikipedia
ソースコード
デスクトップデータベースのフロントエンド。Microsoft Accessに相当する。LibreOfficeを参照のこと。
MongoDBを参照のこと。
Redisを参照のこと。
MicrosoftによるSQLサーバ。C#/VB.NETやASP.NET/ADO.NETとともに利用する。Microsoft SQL Serverを参照のこと。
Microsoftによるカード型データベースで、MS-Officeの上位版に同梱されている。MS-Officeも参照のこと。
Oracleによるとても高額なデータベースサーバ。Oracleを参照のこと。
Delphiの開発元であるエンバカデロ社によるデータベース管理システム。
IBMによるデータベース管理システム。IBMのメインフレーム用のRDBMSである。IBM Db2を参照のこと。
商用のDBMSについては以下が参考になります。
データベース管理システムは、既存のMySQLやPostgreSQLを使わなくても、独自に実装する場合もあります。
たとえば、リレーショナルデータベースをデータモデルとしない場合。自社でデータセンターを運用したり、あるいはシステムの構成上別のデータモデルを使用したい場合などに、独自のデータベース管理システムを作ることができます。
また、スケーラビリティが必要な場合。モバイルやゲームなどで小さな環境で動くデータベースが欲しいとか、あるいはクラスタやスーパーコンピュータなどで並列性を高めて性能や信頼性に妥協しないデータベースを作りたい場合など、独自のエンジンを作ってデータベース管理システムを設計します。
ほかにも、プラットフォームやシステム構成が特殊だったり制限されていたりする場合や、セキュリティやネットワークなどで独自の機能が欲しい場合などにも、データベースを特殊に設計することができます。
また、そもそもデータベースを使う用途が特殊である場合もあります。
たとえば、バージョン管理システムなどは、たくさんの新しいファイルが常にコミットされ、古いデータはアーカイブに格納します。この時、新規のファイルと過去のアーカイブの管理の方法を分けることで、処理を高速化できます。たくさんのテキストファイルの差分を扱う上で、テキスト処理を何度も繰り返すことも多く、リレーショナルモデルが適切でない場合もあります。
また、P2Pのネットワーク通信アプリなどでは、どのネットワークノードがファイルの断片を持っているかを適切に判断しなければなりません。匿名性を高めるためにネットワークセキュリティの機能も必要です。このような場合にも、特殊なデータベースが設計できるかもしれません。
また、Oracleなどの商用データベースを使うよりもコストが安くついて制限もないとか、あるいは自社の別の既存技術を再利用できるといった利点もあります。
こうしたデータベースのバックエンドを作る上で必要となるのは、アルゴリズムの知識です。特に、B-Treeのようなインデックスや検索のアルゴリズムが必要となります。また、トランザクションやロールバック、排他制御のような「きちんと信頼できるデータベース」を作るためには、人並み外れた経験が必要です。簡単にはいかないでしょう。
後日注記:僕は基本的にデータベースについて何も分かっていないので、これ以外にも多くの理由があるだろう。たとえば、冗長性(データを二重にコピーして破損に備える)やフェイルオーバ(ひとつのサーバがダウンしても別のサーバが代わりを務める)を高めるなどといった理由で独自のデータベースを設計する場合もあるだろう。
アルゴリズムも参照のこと。
データベースを独自に実装するのは、とても難しいことだと思われるかもしれません。
ですが、実装の基本から言えば、「ハッシュテーブルを上手く使う」ということが基本となります。
すなわち、Perlにおけるハッシュのようなものを使って、データを複数格納することができたら、それでデータベースの独自実装の最初の一歩は実現できています。
確かに、高速なインデックスを作ったり、SQLのクエリ命令やテーブルの選択・射影・結合などの論理演算を作って、RDBMSにするのは難しいでしょう。
ですが、実際のところ、きちんとしたRDBMSを作る必要はどこにもありません。
そう、独自のデータベースなのだから、独自の仕様にしても構わないのです。
まずは、任意の個数のハッシュテーブルにキーと値を格納できるようなデータベースを作り、それを改良し続ければ、独自のデータベースを実装することはできるでしょう。
後日注記:要するに、表形式のテーブルによって紐づけされたハッシュによるデータを格納・参照・記録できるようにすればいいのです。それだけでRDBMSは実装できます。
2023.08.17-18