[{"content":"Hi, my name is Maksim Gramin. I am a software engineer, consultant, and researcher with a passion for database technologies and SQL. I have extensive experience working with various database systems. In the past, I have worked as a SQL developer on large distributed teams, implementing complex business logic on the database side. Additionally, I have experience as a Java developer and team leader, where we built monolithic and microservices applications and interacted with databases mainly through ORM or similar tools. I am excited to share my experience and develop tools and systems to simplify and enhance working with data.\n","permalink":"https://gramin.pro/about/","summary":"\u003cp\u003eHi, my name is Maksim Gramin. I am a software engineer, consultant, and researcher with a passion for database technologies and SQL. I have extensive experience working with various database systems. In the past, I have worked as a SQL developer on large distributed teams, implementing complex business logic on the database side. Additionally, I have experience as a Java developer and team leader, where we built monolithic and microservices applications and interacted with databases mainly through ORM or similar tools. I am excited to share my experience and develop tools and systems to simplify and enhance working with data.\u003c/p\u003e","title":"About"},{"content":"Percona Community is a great place to share you database knowledge and expirience. In this summer I was lucky to participate in Percona Community Live 2022 and publish my two modest articles on Percona Community Blog. ","permalink":"https://gramin.pro/posts/percona-community/","summary":"\u003cp\u003e\u003ca href=\"http://percona.community\"\u003ePercona Community\u003c/a\u003e is a great place to share you database knowledge and expirience. In this summer I was lucky to participate in \u003ca href=\"http://percona.community/events/percona-community-live-2022\"\u003ePercona Community Live 2022\u003c/a\u003e and publish \u003ca href=\"http://percona.community/authors/maksim_gramin\"\u003emy two modest articles\u003c/a\u003e on \u003ca href=\"http://percona.community/blog\"\u003ePercona Community Blog\u003c/a\u003e.\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n\t\t\t\u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/_XgLLJQ5pZw?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n\t\t\u003c/div\u003e\n\u003c/p\u003e","title":"My thoughts on Percona Community"},{"content":"I have spent a lot of time working with various database systems. I was a SQL and PL/SQL developer on big distributed teams, writing tons of nontrivial SQL queries and implementing tons of complex and tricky business logic on the database side. And I worked as a \u0026ldquo;classical\u0026rdquo; Java developer where we interacted with any databases through ORM, operating mostly JPA annotation and framework properties (hoping to find and turn on a \u0026ldquo;magic\u0026rdquo; parameter fast=true).\nAnd all this time, I have had this feeling that database technologies (especially the part that is related to the comfort and speed of development) are far behind other IT areas (e.g. WEB, infrastructure, integrations, etc.). Working with databases remained slow, laborious, and very risky.\nAnd I\u0026rsquo;m not alone in this feeling. For example, the tagline of dolt database (which provides Git options and MySQL API for your Data) also says about it:\n\u0026ldquo;Software development has come a long way in the last 30 years. Why is your database stuck in 1995?\u0026rdquo;\nMarkus Winand in his talk \u0026ldquo;Modern SQL in Open Source and Commercial Databases\u0026rdquo; discusses the situation where most developers still use SQL-92 standard to this day:\n\u0026ldquo;Still Using Windows 3.1? So why stick to SQL-92?\u0026rdquo;\nAnd now the most interesting. Dan North in his eponymous talk about DevOps things wonders:\n\u0026ldquo;Aren\u0026rsquo;t we forgetting someone?\u0026rdquo;\nAnd the right answer is: \u0026ldquo;Yes, we are forgetting about DBA\u0026rsquo;s\u0026rdquo;. Because DBA\u0026rsquo;s are often separate geographically and organizationally, and databases don\u0026rsquo;t fit into the DevOps story.\nSo let\u0026rsquo;s take a look closer. The DevOps era brought to us \u0026ldquo;Everything as Code\u0026rdquo; philosophy, where any IT area might represent as a plain code, and we can work with it using standard tools and technologies (code editors, control version systems, CI/CD pipelines etc.). And yes, indeed, there are many \u0026ldquo;Everything as Code\u0026rdquo; realizations for many areas, for example:\nPipeline as Code (Jenkinsfile, .gitlab-ci.yml, settings.kts in TeamCity) Infrastructure as Code (Kubernetes, Terraform, Ansible) Diagram as Сode (PlantUML, Graphviz, Mermaid) Documentation as Сode (Markdown, AsciiDoc) Tests as Code (Gatling, Cucumber) But how about \u0026ldquo;Database as Code\u0026rdquo;? It was still a very exotic combination of words, and Dan North offers four simple rules for treating a database like Code:\nAll changes scripted and automated All changes under version control Ability to release on demand DBA\u0026rsquo;s integrated with Dev and Ops It\u0026rsquo;s been six years, and nowadays, it\u0026rsquo;s hard to find a project that doesn\u0026rsquo;t follow these rules (at least the first three). There are a lot of database migration tools and ways to integrate it with your VCS and your CI/CD pipeline. And it\u0026rsquo;s really great.\nHowever, I\u0026rsquo;ve always been excited about a few things:\nDatabase code is not only \u0026ldquo;scripts with changes\u0026rdquo;. It\u0026rsquo;s also DML and all kinds of SQL scripts In addition to DBA\u0026rsquo;s, there are many kinds of data people who intensively work with databases and use SQL Is SQL still the main database language? And I prepared an extended list of \u0026ldquo;Database as Code\u0026rdquo; rules:\nTreat your database or other storage system as a code All changes and operations with the database and all queries (ideally) against the database should be expressed as a plain old code Git (or anything else VCS) is a single source of truth for database code SQL actually is a main database language supported by almost all DBMS SQL is not a bytecode for your data and your database, it\u0026rsquo;s a normal human-oriented program language (why) SQL is designed not only for data, but also for metadata Database code is not only DDL and other migration scripts, DML and all kinds of SQL scripts too Database code is a normal code, and it also needs static analysis, code review (especially by DBA, analysts and business people), tests and automation of it all DBA\u0026rsquo;s and data people should be integrated with Dev and Ops Ability to release on demand. The original version of this list (as well as a list of related tools and resources) is hosted on GitHub. Feel free to create a PR and issues.\n","permalink":"https://gramin.pro/posts/database-as-code/","summary":"\u003cp\u003eI have spent a lot of time working with various database systems. I was a SQL and PL/SQL developer on big distributed teams, writing tons of nontrivial SQL queries and implementing tons of complex and tricky business logic on the database side. And I worked as a \u0026ldquo;classical\u0026rdquo; Java developer where we interacted with any databases through ORM, operating mostly JPA annotation and framework properties (hoping to find and turn on a \u0026ldquo;magic\u0026rdquo; parameter \u003ccode\u003efast=true\u003c/code\u003e).\u003c/p\u003e","title":"Database as Code. Not only migrations"},{"content":"It\u0026rsquo;s hard to find at least two people who would format the same SQL query in the same way. Everyone has their own style and their own arguments. And everyone is absolutely sure that this is the only right way.\nThat was to be expected, because of the declarative nature of SQL. In imperative program languages, we define and control the order of statements execution, and it affects how we format our code. But in SQL query we don\u0026rsquo;t know at all the order of execution in advance and it deprives us of an important reference point. As a result, we have a lot of formatting options.\nBut almost all of these options have one common unpleasant detail. In typography, it is called a river and it is considered to be bad typography. Let\u0026rsquo;s look at a simple query. The river (marked red) tore our query into two jagged parts and makes the code more difficult to read.\nBut legendary Joe Celko in his book \u0026ldquo;Joe Celko\u0026rsquo;s SQL Programming Style\u0026rdquo; sad: let\u0026rsquo;s turn our rivers into axis. Same query but with the axis instead the river:\nLet\u0026rsquo;s look at a more complicated query with subqueries:\nWe immediately visually detect three axis and three corresponding queries. This allows us to quickly and easily find out what this query does.\nIn this post I use my way to build an axis (maybe not the best), surely you can find other methods for this.\nUPD. Hot Reddit discussion\n","permalink":"https://gramin.pro/posts/rivers-and-axis/","summary":"\u003cp\u003eIt\u0026rsquo;s hard to find at least two people who would format the same SQL query in the same way. Everyone has their own style and their own arguments. And everyone is absolutely sure that this is the only right way.\u003c/p\u003e\n\u003cp\u003eThat was to be expected, because of the declarative nature of SQL. In imperative program languages, we define and control the order of statements execution, and it affects how we format our code. But in SQL query we don\u0026rsquo;t know at all the order of execution in advance and it deprives us of an important reference point. As a result, we have a lot of formatting options.\u003c/p\u003e","title":"Rivers and Axis"},{"content":"For many people, SQL is still a “low-level” computer language for data. It is considered an ancient and difficult to understand language, designed for special secret engineers with special secret skills. In this way, a mere mortal should not write SQL queries and should rely on special tools. And we are used to the fact that almost all ORM, DB managers, monitoring tools, and other DB tools generate tons of \u0026ldquo;tricky\u0026rdquo; queries against our data, turning SQL into dumb bytecode. And we can basically just observe this process and hope for the best.\nBut SQL first of all was invented especially for humans, not for machines. So let\u0026rsquo;s treat SQL like a normal computer language (such as Java, C#, C++, etc) and try to follow some generally accepted principles:\nSQL queries are first-class citizens in your system.\nGit (or any other VCS) is the single source of truth for your queries. E.g. one query - one file.\nStatic analysis. Keep your queries in great shape and prevent stupid bugs.\nCode review. Don\u0026rsquo;t hesitate to show your queries to your colleague, DBA, analyst, or someone in the business. And your queries will become clearer, faster, safer, and more valuable.\nTests. Make sure your queries work with the right data.\nAutomate it all.\n","permalink":"https://gramin.pro/posts/sql-is-not-a-bytecode-for-data/","summary":"\u003cp\u003eFor many people, SQL is still a “low-level” computer language for data. It is considered an ancient and difficult to understand language, designed for special secret engineers with special secret skills. In this way, a mere mortal should not write SQL queries and should rely on special tools. And we are used to the fact that almost all ORM, DB managers, monitoring tools, and other DB tools generate tons of \u0026ldquo;tricky\u0026rdquo; queries against our data, turning SQL into dumb bytecode. And we can basically just observe this process and hope for the best.\u003c/p\u003e","title":"SQL is not a bytecode for Data"},{"content":"Michael Stonebraker is a live legend, godfather of databases, relational patriarch, Miles Davis in the database World. He stood at the database roots in the 70s and to this day he stays on the bleeding edge of data technologies. Today we will review his keynote \u0026ldquo;The cloud in your feature\u0026rdquo; from an online conference Postgres Build 2021.\nAll goes to the clouds When you try to hide hardware, wires and pipes under the floor in your office in central London or Frankfurt, cloud guys from Microsoft Azure box up data centers in standard 40 foot shipping containers and drop them around the World in places with cheap power. Guess who will win? On-Premise data centers are very expensive, but cloud solutions become cheaper and cheaper everyday. You have no chance to win these guys.\nDivide compute and storage systems Cloud companies provide amazing elasticity for your business. E.g. in Black Friday days you can upgrade the cluster capacity of your e-commerce systems and make money. In weekdays you can downgrade cluster, even to zero, and saves your money. Unfortunately in a classical database architecture a compute subsystem and a storage subsystem traditionally are strongly bonded, and It devalues cloud capabilities. But new data warehouse systems, such as Snowflake, successfully solves this architecture problem, e.g. using S3 for storage.\nLong live stored procedures In the last decade traditionally server business code on the database side was considered as an ancient and not scalable architectural solution. But when you can divide a DB storage system from a compute system and you can scale this one\u0026rsquo;s separately and independently, stored procedures become a simple, modern and high performance solution again. Your business code and your business data are now together and forever.\n","permalink":"https://gramin.pro/posts/cloudy-with-a-chance-of-databases/","summary":"\u003cp\u003eMichael Stonebraker is a live legend, godfather of databases, relational patriarch, Miles Davis in the database World. He stood at the database roots in the 70s and to this day he stays on the bleeding edge of data technologies. Today we will review his keynote \u0026ldquo;The cloud in your feature\u0026rdquo; from an online conference \u003ca href=\"https://www.postgresbuild.com/registration-talks\"\u003ePostgres Build 2021\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"all-goes-to-the-clouds\"\u003eAll goes to the clouds\u003c/h2\u003e\n\u003cp\u003eWhen you try to hide hardware, wires and pipes under the floor in your office in central London or Frankfurt, cloud guys from Microsoft Azure box up data centers in standard 40 foot shipping containers and drop them around the World in places with cheap power. Guess who will win? On-Premise data centers are very expensive, but cloud solutions become cheaper and cheaper everyday. You have no chance to win these guys.\u003c/p\u003e","title":"Cloudy with a chance of databases"},{"content":"SQL is Esperanto in the data world. But unlike \u0026ldquo;Lingwe Uniwersala\u0026rdquo; SQL became world-known and really common.\nInitially SQL was invented in 70 special for databases. Even then its creators aimed to create a simple and powerful data language for a wide range of users, with not only IT background, such as engineers, scientists, researchers, analytics, managers etc. SQL first of all was made by humans for humans, not for machines.\nCurrently SQL is applied not only in relational databases, but also in NoSQL DB, streaming platforms, In-Memory grids etc. SQL is one of the oldest computer languages widely spread over the World nowadays.\nWhat\u0026rsquo;s the secret of SQL success, health and long life? General SQL advantage is that it is declarative and high-level. We don\u0026rsquo;t explain how we want to receive the data, we describe only what we want to receive. If you want to get employee with names starting with the letter \u0026ldquo;A\u0026rdquo;, then just politely ask your system for it:\nselect name from employee where name like \u0026#39;A%\u0026#39; SQL can be used interactively (and it\u0026rsquo;s good), but this one can also be hidden from users and engineers under the hood in various programs, tools and services. And there is a problem - you, as a data owner, lose control, clarity and safety of the data. In further posts we will be able to discuss \u0026ldquo;database as Code\u0026rdquo; ideas and how they can help us.\n","permalink":"https://gramin.pro/posts/what-is-sql-now/","summary":"\u003cp\u003eSQL is Esperanto in the data world. But unlike \u0026ldquo;Lingwe Uniwersala\u0026rdquo; SQL became world-known and really common.\u003c/p\u003e\n\u003cp\u003eInitially SQL was invented in 70 special for databases. Even then its creators aimed to create a simple and powerful data language for a wide range of users, with not only IT background, such as engineers, scientists, researchers, analytics, managers etc. SQL first of all was made by humans for humans, not for machines.\u003c/p\u003e","title":"What is SQL now?"},{"content":" awesome-db-tools — Everything that makes working with databases easier database-as-code — Database as Code manifesto malewicz — Suprematistic hackable GUI SQL-manager written in SQL itself ","permalink":"https://gramin.pro/projects/","summary":"Projects","title":"Projects"}]