データベースを作ってみたいです

俺は「SQL文を解析して実行」という事にこだわる必要も無いと
思うけどな。そうしたらSQLインジェクションに対抗できる
仕様設計だと考える事も出来るわけで。

>>1が何を考えてこのスレを立てたのかにもよると思うな。
RDBMSとか書いているけれど、テーブルを個別に管理できればそれで良いという考えなのか、
それともリレーションのところまでやるのか。
トランザクションやら、ストアド・プロシージャなどのイメージもあるのか。

ま、俺の場合は、個人で作るものであれば、リレーションは切り捨てるだろうな。
普段作るDBを使ったプログラムは、リレーションはクライアントのプログラムの方で
実現する事が多いから。だから、参照整合性とかの機能の実装にはあまり興味が無い。

VB.NET とかの世界だと、すでに mdbファイル & ADO.NET があるからなぁ。
PHP の世界だと、DBの構築をせずにデータの管理をしたい場合などで
一部使ってもらえるかもしれない。

>>1がイメージしているRDBMSってどんなものなんだろうな。
mdbみたいにファイルとして存在しているものにアクセスするだけで
いいのか。それとも、SQL Server みたいに、アプリとは別にソフトが
立ち上がっていて、それがデータの制御を行う形なのか。
また、ネットワークを通じて複数のアクセスがあるのにも対応できる
かどうかとかあるしね。
ISAMの実装に興味があるような事をいってたけど、そういう部分への
対応はどこまでイメージしているのかな？

こんな感じで管理すると複数のDBを持つのにも対応出来そうだね。
DB名：ディレクトリ名
テーブル名：CSVファイル名

例：DBが「test1」で、その中にテーブル「t1」「t2」「t3」がある場合

/monadb/test1/t1.csv
/monadb/test1/t2.csv
/monadb/test1/t3.csv

>>1は余り興味ないようだけど、独特な設計をしたSQL文という発想もいいかもしれないね。
MonaOSの設計思想はそういうところがあるからね。
多くのユーザに使ってもらえるかを優先的に考え、過去のしがらみにとらわれた物の
延長として考えるのではなく、本当に使いやすいものを、と考える。

処理効率が良いが、別に最適化が必要。
処理効率は悪いが、最適化は不要。

こういうのはどうなんだろ。

とにかく処理効率の速さにこだわったものという方向性は
辞めておいた方がいいのかな。その先にGoogleが居るからｗ
「処理効率は、ある程度良い」くらいｗ

他の人にアドバイスを貰うなら、

＞CSVの操作ぐらいならできそうなのでISAMの実装なんかから始めたいなと思ってます。

ではなく、もう少し具体的なイメージを説明できた方がいい。
試しに自分が利用するシーンを想像して、
　｢こんな感じで検索を指示して、結果を配列に入れる」
　「こんな感じで更新するデータと条件を準備して指示する」
なんてのが明確に出来た方がいい。

擬似的な利用例のスクリプトがあったりするといいかも。

##script(perl)

　use MYDB;
my $db = MYDB->new('mydb/mydbsample.csv');
my @rows;
@rows = $db->select( 'num, key, val', "key='V1.0' and val<'100'" );
$db->close();

##mydb/mydbsample.csv

num,key,val
1,V1.0,150
2,V1.0,50
3,V1.1,120
4.V1.0,15
5,V1.1,20

なんて感じの。上はselectメソッドで key=V1.0 and val<100 な行を返してもらうことを想定。

>>1の考えていることを明確にしないと、助言・指摘をしたい/出来る人たちは説明に困っちゃうと思う。

>>1
エンジンとしてもっとも優れているのは BerkeleyDB でしょうね。
ただしテーブルもSQLもサポートしていません。
もちろんインデックスもです。
しかしリレーショナルデータベースを作るための要素は盛り込まれており
フリーで全ソース公開されています。

このソースを使ってエンジンの勉強をするか、
パーツを利用して独自のシステムを組み上げるとよいのではないでしょうか。

実用は考えていないらしいからなあ
カラクリを確認するのが目的なんだろうなあ
他の人はMonaDBを期待してるのかな？

>>22
そういるルールだからです。
「ぬーやる」バーガーはしってますか？

カラクリは、内部的にはExcelシートの操作でしょ。
で、そのExcelシートはCSVの拡張版。

もっと深いレベルでのノウハウの確認がしたいのかな？

↓こういうことではないかと

ttp://d.hatena.ne.jp/koherent/

>>1の文面やこのスレの流れを見る限り、それは高度すぎる事だと思うｗ

そうか？
ググってたら見つけたんだけど、
このブログ、面白そうなので、オレはしばらく追いかけることにするw

>>1は、ググっても見つけれない、もしくは、ググれないんだから仕方が無いｗ

monaのDB版は高度じゃないといけないのだろうか？ｗ
ム板でしぃ言語を作ろうなんて企画があがって、しばらくしたら
過疎って無くなってしまったなんて事があったけどなｗ
ま、俺は>>1じゃないけれど、主催者側のはっきりとした目的と、
それに共同して意見を行ってくれる方が居るかどうかが
重要なのかな、と思ってる。

このスレは、現時点ですでに３種類の考え方があるように思える。
１．エンジンの仕組みについて勉強しよう派
２．CSV等を使って大まかな概念をつかみさえすれば良いだろ派
３．方向性はわからないけれど、とにかくMonaが出来るのに期待派

当面は統一が上手くできずにずるずる続くんだろうなｗ

3はキモいし寒い
何かが出来たら出来たで「これ2ch発なんだぜ」と自慢するんだろうよ、自分の手柄でも無いのに

そういう自慢をする奴は、普段の言動を見ていると、いたいやつだとすぐに
分かるから別にいいのでは？ｗ
winnyだって、２ｃｈで共同開発したわけじゃないし

ま、スレが生産性の無い書き込みばかりで埋まっていくのはうざいけどな。

で、結局この後、>>1は生産性のある書き込みをせずにこのスレは終息していくのだろうな。

>>1は消えたようだな。１ヶ月ももたなかったかｗ

せっかく新しいデータベースエンジンを作ろうというのに
最初からSQL前提の書き込みしかないね。

やっぱ今からやるなら問い合わせも独自言語でしょう。

メソッド？ｗ

>>36
はやりのNoSQLですか？w

データベースの構造が
CSV のSQL対応高度版なんて
おバカな夢想もいいとろこで
お前ら、アフォかましてないで文献読めよ。

CSVの高度版っぽく見えるのは、ただ単に
理解しやすいようにインターフェースが
そうなってるだけだ。

>>39
かなり遅レスだが、そういうアフォかましている課程を
具体的にやってみて、アフォらしさを学ぶという
目的もあるのでは、といってみるテスト

>>39
亀レスだけど、文献は何がいいのでしょうか？
書籍？ブログ？

トランザクション処理 概念と技法

>>42
紹介ありがとう。
トランザクションの解説だけで1400ページを超えるとかすごいなｗ
上下巻あわせると広辞苑超えるとかどんだけｗｗｗ

トランザクション処理の解説で知った，「知ってるつもりの怖さ」
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040630/146609/

書籍のページ
http://ec.nikkeibp.co.jp/item/books/P81020.html
http://ec.nikkeibp.co.jp/item/books/P81030.html

ちょっとウェブで調べてみたが、理論と実装は別々に考えて学ぶべきみたいだ。
しかし、理解の方はいまいちだ。うまく概要をつかむ方法は無いものか。。。

Perlでファイルの上書きする時、「元のファイルをコピーして、それを
リネームで上書きする」という処理方法をとる事があるけれど、
そういう原理で実装しているという理解じゃだめなのかな？

トランザクション処理
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E5%87%A6%E7%90%86

accessでのフォームやレポートにあたる部分はpostgreSQLやMYSQLでは
どのようにして作成するのですか？

>>46
VB.NETとかC++とかjavaとか、Accessを使って作成します。
Accessはデータベースの入門として使ってもいいけれど、
使いやすさを出す為、データベースの概念とは少しずれた
作りになってる。そこを理解した方がいいよ。

>>47
ありがとうございます。勉強してみます。

>>47
kwsk

>>49
１件のレスで説明できる範囲でいうので、かなり大雑把に言うが、
一般的にいうデータベースエンジンは、Accessのmdbファイルにテーブルだけ
しかないような状態をいう。
そのmdbに、VBだとかのプログラムがデータベースエンジンが持っている
テーブルにデータアクセスしていく構造だ。
だから、postgreSQLやMYSQLには、フォームやレポートにあたるものが存在しないのだ。
VBとかで、別で作るのが当たり前だという前提で作られているから。

また、データベースエンジンは、Accessみたいにファイルで一つ存在している
ものではなく、アプリとして立ち上がっているものだ。（常駐プログラムのようなイメージ）
外部から、SQL文によるアクセスを受けて、テーブルのデータを返す
という処理を行うもの。
このテーブルのデータの管理方法やチューニングの仕様が、
データベースエンジンの種類によって異なる。

あと、トリガとかストアドプロシージャとかはとりあえず省略して学んだ方がいいと思う。

このスレに投稿していい質問かどうか迷うが
キー・バリュー型DBってどうなん？これから主流になっていきそうかい？

>>51
こんな記事を読んだりしながら、予測的な議論をしたいということなのかな？
http://www.atmarkit.co.jp/fjava/rensai4/bigtable01/01.html

俺はこのスレで話をするのは別にいいと思っている。（別にスレを立てても
いいとも思うが、DB板は基本的に人が少ないぞ）
これから主流になりそうかどうかは、その技術の特徴・特性を押さえ、
システムの目的や規模を限定していった方がいいと思う。
こういう場合に強い、こういう場合には向かないとか。
前提を漠然としたまま話をしていってると、極論のぶつかり合いになってしまうから。

別の話で例えると、「クラウド」では、こういう記事を出すなどして、ここで紹介されている
利点にそぐわない場合のシステム構成はどんな場合かなどを整理いくとかからはじめるわけだ。
http://www.atmarkit.co.jp/fjava/column/andoh/andoh50.html
任天堂は、クラウド利用は「部分的であって、全面的にはならないだろう」と
いってるからな。新しい技術というものは、必ずこんな感じに
住み分けになっていくものだろ。

>>1はもう作れたのか？

KVS作るわ。

稲城市立向陽台小学校評判
http://tn.en.fishki.net/26/upload/en/201406/01/1273947/je0gn282.jpg
稲城市立向陽台小学校評判

相模原メディカルサイト歯科日吉サンテラス歯科藤沢なのはな内科スマイル歯科アイ整形外科亀有 リリオ歯科アクロスみなみの歯科足立ハート歯科新宿くろさか歯科熊本ファミリー歯科伊勢原桜台歯科森林公園滑川モール歯科横浜いちょう歯科小田原めぐみ歯科ホワイトスタイル

データベースシステムの勉強の一環でSQL92のリファレンスを見ながら実装始めたけど
実装依存な部分や説明不足な部分が目立って面倒くさいな
とりあえずEntryレベルの実装を進めてるけど完成するのいつになるやら

威勢はいいのに実際に開発できた奴は皆無ですな

今あるオープンソースのいくつかはこうやってできたんでねーの？

開発は進めてるけどオープンソースにするつもりは無いな
金にならんし

それ自体はお金ならないかもしれないけど技術力を買ってそれなりの待遇で雇ってくれる企業はあるはず

◎2ch勢いランキングサイトリスト◎

★ +ニュース
・ 2NN
・ 2chTimes
★ +ニュース新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★ +ニュース他
・ Desktop2ch
・ 記者別一覧
★ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
★ 実況込
・ 2勢
・ READ2CH
・ i-ikioi

※ 要タイトル名検索