徒然なるままにデータベースやその理論
-
- いいね！0
pokarim
@pokarim
それはそれとして、Tutorial D とか SQL の延長線上の文法で再帰的なクエリーがいいかんじに書けるような気があんまりしてない
2020-04-11 23:03:56
_
@apstndb
Tutorial D の実装な Rel は一応 TCLOSE を実装しているから再帰ができるが、実用的な DBMS かというと…ってところではありますよね
2020-04-11 23:08:50
pokarim
@pokarim
RDBへの文句がいいたいわけじゃなくて、たとえばDOMを含むようなUIレイヤーで使える小回りがきくデータベースモデルが欲しいんだよね
2020-04-11 23:10:45
_
@apstndb
GraphQl が盛り上がっているので グラフ DB がそろそろまた盛り上がるかもしれないし、それに乗じて SQL のプロパティグラフ標準化も気になるところではある
2020-04-11 23:14:36
_
@apstndb
再帰 CTE がもう少し手軽に使えるシンタックスならなー。そういう意味だと Oracle の CONNECT BY はわりと嫌いじゃなかったりします。
2020-04-11 23:18:17
pokarim
@pokarim
こういう雑に書くことをやって突っ込まれたりしてやっぱり実装して具体的なものを提示するしかないなとなってモチベーションが回復するわけです
2020-04-11 23:20:02
pokarim
@pokarim
最初からテーブルよりもより小さい構造であるMapとかArrayとかを考えて、それらのネスト構造があったときにRDBのように宣言的に扱うにはどうすればいいかという方向です
2020-04-11 23:23:59
pokarim
@pokarim
ここでいう宣言的とはなにかについては具体的な中身があって、RDBMSである程度成功しているクエリ自体の記述とインデックスや実行計画が分離できれば宣言的と呼んでよいだろうという感じです
2020-04-11 23:26:29
pokarim
@pokarim
インデックスとオプティマイザと同じかそれよりも重要視してるのはincremental computing のことでRDBMSでいうとマテリアライズド・ビューのincremental refreshがほぼこれににあたる。仮想DOM的な更新もこれの範疇に含めてしまうことができると思ってる。
2020-04-11 23:33:12
pokarim
@pokarim
インデックスとオプティマイザみたいなやつがなぜ関係という構造の上でうまくいくのかは良いとして、なぜ関係でなければいけないのかというのはまったく自明ではなくてずいぶん長い間こたえがわからなかったのだけど、関係が基本である必然性は特にないという答えがでた。
2020-04-12 00:55:33
_
@apstndb
SQL RDBMS におけるテーブルに相当するのは永続化された RELATION 型の変数、 Relvar であり、単に RELATION 型の演算が定義されているだけだよというのが TTM 的にはありがちなアレかな。Tutorial D の VAR で REAL と VIRTUAL の区別があるのは RELATION だけだけど、他の型に対しても拡張できそう
2020-04-12 00:56:44
pokarim
@pokarim
データ構造同士の代数的な演算が良い感じに定義されていればそれで十分だし、そう考えると関係というのはプリミティブとしては大きすぎるくらいなんだよね
2020-04-12 00:59:46
_
@apstndb
リレーション以外をファーストクラスにするとどうやって永続化したり更新するのかって話になるし、ファーストクラスはリレーションだけで足るという前提でやっている感じですよね。
2020-04-12 01:00:11