Throughout the project it seems
I make an effort to discredit SQL.
As a matter of fact, I like SQL.
And I like SQL databases for the same reason
I like ProfaneDB, that is data normalisation.
Indeed, ProfaneDB doesn’t want to be that different from relational DBs, and it could very well at some point become a Not-only-SQL DB, meaning that a SQL database can be used as storage backend.
The reason behind ProfaneDB
There is only one reason that really drives ProfaneDB development, and that is DRY.
You already define your Protobuf schema,
then why would you want to write it again
as SQL CREATE statements?
What if we could just map a Protobuf definition to SQL?
message User {
string email = 1;
Passport passport = 2;
}
message Passport {
string number = 1;
Date expiry_date = 2;
}
would become
CREATE TABLE users (
user_id INT PRIMARY KEY,
email VARCHAR(255) UNIQUE
)
CREATE TABLE passports (
passport_id INT PRIMARY KEY,
user_id INT,
passport_number VARCHAR(255) UNIQUE,
expiry_date DATE
)
and the FOREIGN KEY constraint is still missing…
And still, having the SQL table there doesn’t provide an easy way to store a Protobuf object directly.
ProfaneDB wants to address just this, and why not, in future directly mapping to SQL!