Not a DB
The author tells about the vicissitudes of brewers, manufacturers of databases, themselves, and briefly about how to design applications. I found the instructive part of the article useful.
In the United States in the 1920s, the production, sale and import of alcoholic beverages was prohibited by constitutional amendment. The amendment was canceled after 13 years. During this ban, the beer industry has died.
In 1933, when the ban was lifted, several grain giants began to brew beer. They completely monopolized the market. And for almost 50 years, we in the States drank this carbonated urine and called it “beer”. The only way to tolerate this taste was to drink it very cold.
Being a teenager in the 60s, I never understood his appeal. Why beer? This is a pale yellow, nasty liquid obtained from the urine of sick boars. And I could not find a single weighty plus.
')
In 1984 I went to England, and the blinders fell from my eyes. I finally understood. I first tried the beer and it turned out good about .
Since then, the beer situation in the United States has improved significantly. New brewing companies are growing all over the country like mushrooms, and in most cases the beer they make is really very good. We have nothing so beautiful as bitter (bitter hopped beer), but we are catching up.
In the 80s several large companies monopolized the market with their databases. They did this by instilling fear, uncertainty and doubt among managers and marketers. The word “relational” has become synonymous with “quality,” and any other way of storing data has become forbidden.
In those days, I was a lead developer. Our system measured the quality of T1 communication lines. Our data model was relatively simple, and we stored the data in simple files. It worked fine.
But our marketer kept telling us that we should use a relational database. He said that customers would need it. It seemed to me that this was a strange desire, because at that time I hadn’t yet been sold a single system, and not a single buyer had ever been interested in our way of storing data. Simple files were banned.
From the point of view of me, the leading developer responsible for the quality of software, relational databases are big, rough, slow hemorrhoids. We did not have complex requests. We didn’t need powerful reporting capabilities. We definitely didn’t need a multi-megabyte process in memory and devouring cycles. (Consider it was the 80s.) So I fought off this idea as best I could, because it was the wrong technical decision.
It was politically short-sighted of me. Within a few months, a hardware engineer who managed to write a couple of lines of code was transferred to the software group. He was gradually assigned more and more responsibilities, and in the end, he became known as my co-manager. He and I “shared” the responsibility for managing the development team.
Yeah, of course. For sure. Zhelezyachnik without real programming experience was going to “help” me manage the team. And what do you think was the first item? Why not use a relational database in our system!
I quit a month later and began a career as a consultant. It was the best career move I've ever done. The company from which I quit no longer exists. I think they did not earn a penny.
I watched the relational database market in the 90s. I have seen all other data storage technologies, such as object databases and databases in B trees, degenerate and die. Like the brewers in the 20s. By the end of the 90s only giants survived.
These giants were driving a wave. They were gods. They ruled. During the dot-com bubble, one of them got the nerve to run a TV commercial that claimed their system was “the power that controlled the Internet” (the power that drove the internet). It reminded me of the slogan of beer from the 70s - “I should zohvatit all the buzz I can.” Oh my God.
Then I watched in horror as the team behind the team put the databases at the forefront of their systems. They were convinced by the endless fraud that the data model is the most important aspect of the architecture and the database is the heart and soul of the project.
I witnessed a new post. Database administrators! Simple programmers can not trust the data - that was the marketing rubbish. The data is too valuable, too fragile, too easily damaged by this unskilled peasant. We need special people for data management. People trained by database vendors. People who will protect and promote the messages of the giants of the DBMS to the market: “Databases are the basis. The basis of the system, the basis of the enterprise, the basis of the world and the universe itself. BU-GO-HA-HA-HA-GA !!! ”
I watched as SQL crawled into every nook and cranny of the systems. I cried out in horror because of the systems in which SQL leaked into the interface. I endlessly cursed the transfer of all business logic to stored procedures. I shuddered and shuddered to read mailing programs written in SQL.
I hit the alarm, seeing as tables and rows penetrate into the source code of the system behind the system. I signaled the danger. I warned. I said that the technique turned into an amoeba, absorbing everything in the field of view. But I knew that all my warnings were a voice crying in the wilderness.
And then, in the first decade of the 21st century, the ban was lifted and the NOSQL movement was born. I considered this as a miracle, a shining light of illumination. Finally, someone realized that there might be systems in the world that do not need large, fat, slow, expensive memory-devouring relational databases!
I watched with affection as BigTable, Mongo, CouchDB, and other cute little database systems began to grow, just like small breweries in the 80s. Beer is back! And it becomes tasty.
But then I noticed something. Some systems using these cute, simple, elegant non-relational databases have been designed around databases . Databases wrapped in sparkling new frameworks are still at the core! This is in the minds of designers poisonous relational advertising crap. They still make a fatal mistake.
“Stop!” I shouted. - “Stop! You do not understand. You do not understand. ”But the impulse was too great. There was a huge pleiad of frameworks, it collapsed on our industry and took possession of the world. These frameworks spanned databases and fought to capture and hold the core of your application. They were designed to manage and improve databases. It was even claimed that they could turn the relational database into a NoSQL database. And the frameworks shouted loudly to the whole world: “Rely on me and I will make you free!”.
The title of this article is “Not a DB”. Perhaps after these words, you got a hint as to why I called her that.
The foundation of your application is not a database. And not one or more frameworks that you can use. The basis of your application is its use scenarios.
I’m losing my mind when I hear a developer describe his project in the style of "Tomcat with Spring and Hibernate on Oracle". The wording itself puts frameworks and databases at the forefront.
What do you think the architecture of this system looks like? Do you think
Will you find usage scenarios at design basis? Or do you find that the source code is tailored to fit better into the framework model? Do you notice that business objects suspiciously resemble table lines? Does the entire data schema and framework overshadow?
This is what the app should look like. Usage scenarios should be the most important and most visible architectural objects. Usage scenarios are the foundation. Is always! Databases and frameworks - details! You do not need to choose them from the beginning. You can postpone them until later, until all usage scenarios and business logic have been formulated, recorded and verified.
When is it better to decide on a data model? When you know what data objects are, how they are connected and how they are used. When will you find out? When all use cases and business rules are written and verified . By the time you have decided on all the queries, relationships and data elements and you can build a data model that is perfectly suited to the database.
Something to change if you use NoSQL database? Of course not! You still focus on how the usage scenarios are recorded and validated, not paying attention to the type of database before even thinking about the database.
The database, participating in the early design stages, will distort the architecture of the project. She will fight for the heart of the system, and once penetrated there, it will be fixed there like a gum in her hair. We must try to keep the database in the heart of your system. It is necessary to constantly say “No” to the temptation to take up the database rather.
Ahead is an interesting time. The time when the ban on various storage technologies has been lifted, and we can freely experiment with many new approaches. But while playing with CouchDB, Mongo and BigTable, do not forget: A database is just a component that does not require immediate solutions .
In the United States in the 1920s, the production, sale and import of alcoholic beverages was prohibited by constitutional amendment. The amendment was canceled after 13 years. During this ban, the beer industry has died.
In 1933, when the ban was lifted, several grain giants began to brew beer. They completely monopolized the market. And for almost 50 years, we in the States drank this carbonated urine and called it “beer”. The only way to tolerate this taste was to drink it very cold.
Being a teenager in the 60s, I never understood his appeal. Why beer? This is a pale yellow, nasty liquid obtained from the urine of sick boars. And I could not find a single weighty plus.
')
In 1984 I went to England, and the blinders fell from my eyes. I finally understood. I first tried the beer and it turned out good about .
Since then, the beer situation in the United States has improved significantly. New brewing companies are growing all over the country like mushrooms, and in most cases the beer they make is really very good. We have nothing so beautiful as bitter (bitter hopped beer), but we are catching up.
In the 80s several large companies monopolized the market with their databases. They did this by instilling fear, uncertainty and doubt among managers and marketers. The word “relational” has become synonymous with “quality,” and any other way of storing data has become forbidden.
In those days, I was a lead developer. Our system measured the quality of T1 communication lines. Our data model was relatively simple, and we stored the data in simple files. It worked fine.
But our marketer kept telling us that we should use a relational database. He said that customers would need it. It seemed to me that this was a strange desire, because at that time I hadn’t yet been sold a single system, and not a single buyer had ever been interested in our way of storing data. Simple files were banned.
From the point of view of me, the leading developer responsible for the quality of software, relational databases are big, rough, slow hemorrhoids. We did not have complex requests. We didn’t need powerful reporting capabilities. We definitely didn’t need a multi-megabyte process in memory and devouring cycles. (Consider it was the 80s.) So I fought off this idea as best I could, because it was the wrong technical decision.
It was politically short-sighted of me. Within a few months, a hardware engineer who managed to write a couple of lines of code was transferred to the software group. He was gradually assigned more and more responsibilities, and in the end, he became known as my co-manager. He and I “shared” the responsibility for managing the development team.
Yeah, of course. For sure. Zhelezyachnik without real programming experience was going to “help” me manage the team. And what do you think was the first item? Why not use a relational database in our system!
I quit a month later and began a career as a consultant. It was the best career move I've ever done. The company from which I quit no longer exists. I think they did not earn a penny.
I watched the relational database market in the 90s. I have seen all other data storage technologies, such as object databases and databases in B trees, degenerate and die. Like the brewers in the 20s. By the end of the 90s only giants survived.
These giants were driving a wave. They were gods. They ruled. During the dot-com bubble, one of them got the nerve to run a TV commercial that claimed their system was “the power that controlled the Internet” (the power that drove the internet). It reminded me of the slogan of beer from the 70s - “I should zohvatit all the buzz I can.” Oh my God.
Then I watched in horror as the team behind the team put the databases at the forefront of their systems. They were convinced by the endless fraud that the data model is the most important aspect of the architecture and the database is the heart and soul of the project.
I witnessed a new post. Database administrators! Simple programmers can not trust the data - that was the marketing rubbish. The data is too valuable, too fragile, too easily damaged by this unskilled peasant. We need special people for data management. People trained by database vendors. People who will protect and promote the messages of the giants of the DBMS to the market: “Databases are the basis. The basis of the system, the basis of the enterprise, the basis of the world and the universe itself. BU-GO-HA-HA-HA-GA !!! ”
I watched as SQL crawled into every nook and cranny of the systems. I cried out in horror because of the systems in which SQL leaked into the interface. I endlessly cursed the transfer of all business logic to stored procedures. I shuddered and shuddered to read mailing programs written in SQL.
I hit the alarm, seeing as tables and rows penetrate into the source code of the system behind the system. I signaled the danger. I warned. I said that the technique turned into an amoeba, absorbing everything in the field of view. But I knew that all my warnings were a voice crying in the wilderness.
And then, in the first decade of the 21st century, the ban was lifted and the NOSQL movement was born. I considered this as a miracle, a shining light of illumination. Finally, someone realized that there might be systems in the world that do not need large, fat, slow, expensive memory-devouring relational databases!
I watched with affection as BigTable, Mongo, CouchDB, and other cute little database systems began to grow, just like small breweries in the 80s. Beer is back! And it becomes tasty.
But then I noticed something. Some systems using these cute, simple, elegant non-relational databases have been designed around databases . Databases wrapped in sparkling new frameworks are still at the core! This is in the minds of designers poisonous relational advertising crap. They still make a fatal mistake.
“Stop!” I shouted. - “Stop! You do not understand. You do not understand. ”But the impulse was too great. There was a huge pleiad of frameworks, it collapsed on our industry and took possession of the world. These frameworks spanned databases and fought to capture and hold the core of your application. They were designed to manage and improve databases. It was even claimed that they could turn the relational database into a NoSQL database. And the frameworks shouted loudly to the whole world: “Rely on me and I will make you free!”.
The title of this article is “Not a DB”. Perhaps after these words, you got a hint as to why I called her that.
The foundation of your application is not a database. And not one or more frameworks that you can use. The basis of your application is its use scenarios.
I’m losing my mind when I hear a developer describe his project in the style of "Tomcat with Spring and Hibernate on Oracle". The wording itself puts frameworks and databases at the forefront.
What do you think the architecture of this system looks like? Do you think
Will you find usage scenarios at design basis? Or do you find that the source code is tailored to fit better into the framework model? Do you notice that business objects suspiciously resemble table lines? Does the entire data schema and framework overshadow?
This is what the app should look like. Usage scenarios should be the most important and most visible architectural objects. Usage scenarios are the foundation. Is always! Databases and frameworks - details! You do not need to choose them from the beginning. You can postpone them until later, until all usage scenarios and business logic have been formulated, recorded and verified.
When is it better to decide on a data model? When you know what data objects are, how they are connected and how they are used. When will you find out? When all use cases and business rules are written and verified . By the time you have decided on all the queries, relationships and data elements and you can build a data model that is perfectly suited to the database.
Something to change if you use NoSQL database? Of course not! You still focus on how the usage scenarios are recorded and validated, not paying attention to the type of database before even thinking about the database.
The database, participating in the early design stages, will distort the architecture of the project. She will fight for the heart of the system, and once penetrated there, it will be fixed there like a gum in her hair. We must try to keep the database in the heart of your system. It is necessary to constantly say “No” to the temptation to take up the database rather.
Ahead is an interesting time. The time when the ban on various storage technologies has been lifted, and we can freely experiment with many new approaches. But while playing with CouchDB, Mongo and BigTable, do not forget: A database is just a component that does not require immediate solutions .
Source: https://habr.com/ru/post/145061/
All Articles