設計原則

basedbは、アーキテクチャ文書をもとに設計されました。リポジトリのdocs/architectureにある、16の章からなる文書です。その第00章では25の設計判断が定められています。ここでは、その考え方を紹介します。

データは形式ではなくテーブルである

ユーザーのデータベースはPostgreSQLのスキーマであり、テーブルはテーブル、フィールドはわかりやすい名前の付いた型付きの列です。EAV（エンティティ・属性・値）も、何でも詰め込むJSONドキュメントも、意味のわからない名前もありません。カタログ_basedbはこれらのオブジェクトを記述しますが、それらを置き換えるものではありません。

その意図された帰結として、直接SQLは正当な使い方です。制約はデータベースに設定され、履歴はトリガーで記録されます。書き込みがアプリケーションを経由することを前提にしている部分は、何もありません。

権限の判定ポイントは1つだけ

インターフェース、REST API、MCPサーバー、共有フォーム、Webhookは、すべてコアにある同じ権限適用ポイントを通ります。インターフェースも他と同じAPIの利用者の1つにすぎず、非公開ルートもサービス用トークンもありません。見ることのできないリソースは、存在しないリソースとまったく同じ応答を返します。

コアが判断し、アダプターが変換する

TypeScriptのモノレポです：@basedb/coreがすべてのロジック（カタログ、DDLエンジン、権限、行、履歴）を担い、apps/api（Hono）、apps/mcp、apps/web（Next.js）は、互いに呼び出し合わないアダプターです。インターフェースがコアに依存することはなく、HTTPで通信するだけです。

判断なしには何も失われない

削除は退避であって、破棄ではありません。削除したテーブルは行を保持し、退避用の名前でSQLから読むことができ、復元もできます。物理名を変更しても、古い名前はエイリアスによって引き続き利用できます。パージはシステム管理上の判断であり、その前に検証済みのエクスポートが行われます。

PostgreSQL、それだけ

PostgreSQL 16以上。必須の外部依存はありません。メッセージキューも、キャッシュも、検索エンジンも不要です。Webhookのキュー、履歴のドレイン、レート制限は、すべてデータベースかプロセスの中で完結します。

さらに詳しく

章	内容
00	基本的な設計判断と、エラーコードの一覧
01	命名とスラッグ化
02	信頼できる唯一の情報源、カタログ_basedb
03	DDLエンジンとマイグレーション
04	フィールドの型とPostgreSQLへの対応
05	権限
06	ライフサイクル：名前の変更、削除、パージ
07	履歴
08	REST APIとWebhook
09	MCPサーバー
10	ソフトウェアアーキテクチャ
11	インターフェース
12	AI連携
13	認証
14	環境
15	共有フォーム