これは、ボトムアップ方式が他のどの方式よりも優れていると言うことではなく、ほとんどの場合、より実行可能です。 実際、たとえば店を開いたりDEを作成したりする人は小さく始まり、徐々に開発されます。 しかし、彼がすでにAuchanに匹敵する店舗チェーンで店舗を開発している場合、またはKDEを作成している場合、次回は小さく始めず、計画に長い時間を費やし、すぐに大きなプロジェクトを実現します。 開発中に初めてフィードバックを受け取る人、2回目も、すでに店舗ではなく一連の店舗を開発しているのに、以前に開発されたプロジェクトからの応答が返されます。
大企業では、開発は上から下に行われることがよくあります。 残念ながら、このテクニックのために単純なパフォーマーは創造性の要素を失い、自分の仕事を嫌い始めます。 Paulは彼のエッセイで、 ビジネスがオープンソースから学べることは 、ソフトウェア会社が会社にとって興味深い分野ですでに開発しているプログラマーのチームに投資するとき、興味深い開発モデルを提案しました。 このように、階層は消え、上司の部下と開発者はより熱意を持って仕事をし、会社はマーケティング、流通を扱い、プログラマーの独自のスタッフを含みません。 Habréの読者が耳にする例の中で-F＃言語。DonSymeは長い間働いており、Microsoftは次のスタジオリリースで主流にすることを決めました。
彼のエッセイでは、ポールは計画、執筆速度、変更の容易さよりも実践の普及に焦点を当てています。 残念ながら、開発者向けの多くのツールはこれらの原則に関係なく作成され、支配的な上司と部下の関係を堅持する企業を対象としています。 多くの場合、XPスタイルで作業する場合、データベースとの相互作用は喉の骨のように上昇します。テストの難しさ。 コードの不均一性-Javaで考える必要がありますが、宣言型SQLでは、相互にマッピングすることのニュアンスに留意してください。 データベースとの対話に関与する大量の不要なコードと不要な抽象化、およびこの不名誉を修正するために設計されたソリューションは、本質的にこれから生じるすべての問題を伴うコード生成です。
この混乱を最初に認識したのは、動的言語で書いている人々であり、この問題を修正しようとしました。 そのため、couchdb、strokedb、simpledbが登場しました。 このソリューションは小規模なプロジェクトに適していますが、Yandexレベルの企業は、時の試練に合格していない下位区分の基盤を維持しないと思います。
庭で95年間、目を覚まし、Yandexを作成する、つまりWeb検索用のエンジンを作成することにしたと想像してください。 明らかに、タスクで最も興味深いのは情報の分析であり、保存方法ではないため、すぐにこのタスクを攻撃しました。 部分的には決定されており、投資家を見つけるための最初のプロトタイプを作成する必要があります。 ここでデータストレージなしで実行できないことは明らかですが、データベース構造を選択しなかったことは理解できます。その後、起動されるまでに100回変更されるため、データベースを操作するための100回の回避策を書く見込みがあるため、病気になります。
したがって、将来の開発を制限しないソリューションが必要です。要件が変更されても簡単に変更でき、いつでもこのソリューションをリレーショナルデータベースに迅速に転送できるという特性があります。 また、不均一性を取り除き、テストを容易にするために、開発が行われている言語でデータベースエンジンを記述することは適切なソリューションであり、インタラクションメソッドをインターフェイスに入れてインターフェイスのみで動作するため、テスト済みのDBMSへの移行が実行されると結論付けていますこのインターフェースと一致する、データベースとの相互作用の実装。
独自の単純なデータベースエンジンを作成する場合、タプル、リスト、およびリストの理解をサポートする言語を使用してこれを行うのは簡単です。データベースエンジンの実装は、直面している主なタスクではないため、この言語が望ましい高レベルで、通常の構文を持ち、一般的なパラダイムをサポートしていました。 あなたはすでに私がネメルについて書いていると推測したと思います。 以下に、データベースエンジンの実装の基本的な例を示します。
基本スキームは次のとおりであると想定します。
DROP TABLE IF EXISTS Author;
CREATE TABLE Author (
ID INT AUTO_INCREMENT NOT NULL ,
Firstname VARCHAR (500) NOT NULL ,
Lastname VARCHAR (500) NOT NULL ,
PRIMARY KEY (ID)
);
DROP TABLE IF EXISTS Journal;
CREATE TABLE Journal (
ID INT AUTO_INCREMENT NOT NULL ,
Title VARCHAR (500) NOT NULL ,
PRIMARY KEY (ID)
);
DROP TABLE IF EXISTS Article;
CREATE TABLE Article (
ID INT AUTO_INCREMENT NOT NULL ,
Title VARCHAR (500) NOT NULL ,
JournalID INT NOT NULL ,
AuthorID INT NOT NULL ,
CONSTRAINT `journal_id` FOREIGN KEY (JournalID) REFERENCES Journal(ID) ON DELETE CASCADE ,
CONSTRAINT `author_id` FOREIGN KEY (AuthorID) REFERENCES Author(ID) ON DELETE CASCADE ,
PRIMARY KEY (ID)
);
* This source code was highlighted with Source Code Highlighter .
この構造とそれに対するいくつかの要求は、次のように実装できます。
public interface IDB
{
AddAuthor(firstName : string , lastName : string ) : int ;
GetAuthor(firstName : string ) : list[ int * string * string ];
}
public class MyDB : IDB
{
public this () { Author = []; Journal = []; Article = []; ID = 0; }
public Author : list[ int * string * string ] { get ; set ; } // (ID, Firstname, Lastname)
public Journal : list[ int * string ] { get ; set ; } // (ID, Title)
public Article : list[ int * string * int * int ] { get ; set ; } // (ID, Title, JournalID, AuthorID)
public ID : int { get ; set ;};
public AddAuthor(firstName : string , lastName : string ) : int
{
ID++;
Author = (ID,firstName,lastName)::Author;
ID
}
public GetAuthor(firstName : string ) : list[ int * string * string ]
{
$[(id,first,last)|(id,first,last) in Author, first==firstName]
}
}
* This source code was highlighted with Source Code Highlighter .
このアプローチの使用は、開発時に基本構造が明らかでないタスク、Yandexの例のように他の何かに重点が置かれているタスク、および基本構造が小さいタスクで便利であると思われます。
