直接SQL

これこそがbasedbの存在理由です：テーブルは本物のテーブルです。どのPostgreSQLクライアントでも、その名前のまま読めます。

名前

オブジェクト	物理名	例
データベース	スキーマb_<tenant>_<nom>	b_t4z56fq_ventes
ステージング環境	接尾辞付きのスキーマ	b_t4z56fq_ventes_recette
テーブル	スラッグ化した名前	opportunites
フィールド	スラッグ化した名前	echeance
リレーション	<table cible>_id	clients_id
SQLビュー	データベースのスキーマ内の技術名	factures_a_encaisser

各データベースのAPIとMCPのドキュメントページにすべての名前が載っており、psqlの\dで説明（COMMENT ON）を確認できます。

インターフェースで

タブバーの +、またはデータベースの ⋯ メニュー → SQLクエリ：シンタックスハイライトと補完付きのエディターで、結果はテーブルと同じグリッドに表示されます。

• 各自が自分の権限で読みます：管理レベルならデータベース全体を、書き込みも含めて扱えます。他のメンバーは読み取り専用のSQLを書き、閉じられたテーブルは存在せず、非表示のフィールドは消えます。
• クエリはテーブルの下に保存でき（自分用、データベース全体用、またはグループ用）、必要ならSQLビューにできます。テーブルと並んで表示され、psqlからも読める本物のPostgreSQLビューです。

詳しくはクエリとSQLビューをご覧ください。

psqlから

付属のdocker-compose.ymlでは、PostgreSQLは127.0.0.1:5432に公開されています：

psql "postgres://basedb:<POSTGRES_PASSWORD>@localhost:5432/basedb"

SET search_path = b_t4z56fq_ventes;

SELECT o.nom, o.montant, c.nom AS client
FROM opportunites o
JOIN clients c ON c._id = o.clients_id
WHERE o.statut = 'gagne';

このアカウントはデータベースの所有者であり、すべてを読み取れ、basedbの権限は適用されません。BIツール用には、専用のGRANTを持つ別のロールを作成してください。テーブルに行のルールが設定されている場合、PostgreSQLの行単位セキュリティ（RLS）が適用されます：そのようなロールは、BYPASSRLS属性か自分専用のポリシーがない限り、どの行も見ることができません。

SQLで書き込む

書き込みもできます。制約（単一選択、リレーション、URL、必須）はPostgreSQLが守っており、インターフェースと同じように無効な値を拒否します。そして書き込みは履歴に記録されます。履歴には、書き込んだセッションとともに「直接SQLセッション」として表示され、他の書き込みと同じように元に戻せます。

注意

SQLで構造を変更する（ALTER TABLE）と、basedbのカタログを迂回することになり、カタログはその変更を把握できません。インターフェース、API、またはエージェントの提案を使ってください。マイグレーションエンジンが計画を立て、ロックを短く保ち、カタログを正確に維持します。