DBでMAX

 DBでIDなんてものはオートインクリメントにしておけよと思うのだけど

select

    max(id)

from

    TBL_A;

こういうのでIDのMAXを取得してインクリメントしてインサートというパターンがある

ところで、上記SQLには大問題がある

データが入ってない場合、NULLになってしまうのだ

するとMAX取得ができないでエラーとなる

仕方ないのでこうする

select

    COALESCE(MAX(id),-1)

from

    TBL_A;

これだと一件もデータがないときには-1となり、インクリメントして０

そのままインサートしてIDが０のデータが出来上がる

次からはMAXを取得するので0が取得できるため、インクリメントして１

そのままインサートしてIDが１のデータが出来上がる

元からダミーデータが入っているような環境だと気が付かないので要注意だ

ついでに書いておくけど

DBにテーブルを作るとPrimaryKeyが必要になる

これが何のために使われるかというと２点あって

１．重複しないため

２．ソートのため

ここで２はあまり重要ではない

IDでソートするパターンなんてあまりないからだ

なので重複しない目的のためならUDIDのようなものを割り振っても構わないはずだ

しかし、本当にそうか？

実はDBのPrimaryKeyとは、インデックスがあるため、順番を検索してインサートが行われる

すると、UDIDの山を一生懸命探しに行くことになるのでインサートは遅くなる

ちなみに大手のDBでは、インデックスを３つ作成するとインサートが１０倍遅くなると言う

わたしはこの点、もはやDBの構造的問題に思えて仕方ない

ここ数年かけてXML DBについて考えてきたが

XML DBであればこういうソートだのインデックスだのいう概念をうまく包括できると考えている（インデックスが自動的に勝手に存在するようになる）

その果てにたどり着いたのはファイルシステムで表現してしまえばいいではないかという結論だった（様々な考察をして利点があると考えた）

しかし、次にファイルシステムでは足りないということにも気が付いた

そこで既存ファイルシステムでは何が嫌なのかという点を列挙してみることにした

1. 同じフォルダに同名のファイルやフォルダが作れない

2.ファイルやフォルダに任意のプロパティを設定できない

3.ファイルやフォルダの順序が明確ではない

4.パスに限界がある

何言ってるかわからないかも知れないが

わたしは非常識な事を言っているのである

逆に言うと常識で考えないでほしい

WindowsでもLinuxでもファイルシステムはかなり昔からあるものを拡張し続けている

しかし、上記４点を改善できれば、XMLのタグやInnerTextなどをそのままファイルシステムで表現できるようになる

もちろん、JSONやYAMLもファイルシステムに置き換えられるだろう

早速ファイルシステムを考え始めた（いまさらか？）

世の中にはFUSEというものがある

これを使うと結構簡単に実現できるかもしれない

あとは設計製造だ

今ここまでたどり着いた