Story of A NoSQL “IfDB” Project Suspended in 2004

> for Japanese Pages

Story of A NoSQL “IfDB” Project Suspended in 2004
1. A story over 14 years ago
The keyword NoSQL was first proposed in 1998.
However, it did not penetrate at all.
And in early 2009, NoSQL gradually began to penetrate by re-proposing a person.

The other day, I was sorting out my own source code, I stayed in my eyes in the source code of the last update November 2004.
The source code is a NoSQL scratch source code called “Document Oriented DB” in recent years.

NoSQL's first proposal was in 1998.
We were developing from 2003 to 2004.
NoSQL began to penetrate the world in 2009.
The year of NoSQL's popularization is much later.
In short, it is a project more than 5 years ago from the re-proposal of NoSQL.
That is a story of over 15 years ago.

What I thought about this source code again is that “such technical innovation approach is not wrong.”
And one technology I developed at that time is also useful for my AI research now.
I want to say “Don't give up” to such innovative technicians.
And I would like to thank the engineers that developed NoSQL.


2. About NoSQL Project IfDB
Well, let me briefly outline this project.
This project name has been changed several times as follows.

FileDB -> IniDB -> IfDB
At that time, we were not conscious of the word NoSQL at all.
Rather, we probably didn't know NoSQL.
The CRUD processing of data is flow as follows.

Array -> Query Command -> Ini File -> Array of Result Set
We also implemented SQL-like syntaxes.
And what we emphasized was to enable direct editing of Ini File rather than via commands.
This is because at that time JSON was not generic.
These are still useful depending on applications but I have been busy with other projects and forgotten over the last ten years.
However, I have memories that the development speed and the improvement cycle have increased very much using these method.


3. The reason why I developed Ifdb
The reason why I developed this technology 14 years ago.
I saw this source code after a long time, but the concept is not much different from the current document-oriented DB.
14 years ago, I was troublesome that relational model design but I had doubts about waterfall-like data model design and schema restrictions.
This is because the scalability of the project is compromised by staticizing the relational model and schema.
At that time, all the DBA's arranged their mouths and said:

“It's because the design of the data model is bad.”
“Study the data model more.”

However, the more I learned data models, the more my discomfort grew.
I think that I probably wanted to do agile development at that time.
At that time I probably did not even know about agile development.
The initial proposal time for agile development is also in the 1990's.


4. Conclusion
The de facto standard of technology is a very important factor in business.
However, the number of engineers who do not think about the simple thing “why the de facto standard is important” has increased.
They arrange their mouths and make excuses like this:

“Not a de facto standard = evil”
“We don't need scratch development.”

You don't forget what you are developing in scratch development products of me or someone.

Both Sustaining Innovation and Disruptive Innovation are important.

It is always proved by the times.