4 ms·

Yeah, sadly, this is not too much of an exaggeration. I've worked on teams that insisted they needed DynamoDB, because, well, Dynamo is for "Big Data", and they

Yeah, sadly, this is not too much of an exaggeration. I've worked on teams that insisted they needed DynamoDB, because, well, Dynamo is for "Big Data", and they certainly wouldn't work somewhere that had "Small Data"! Replace the buzzwords/products as applicable; you could actually probably just scramble them and it'd work just as well, since someone out there thinks "RabbitMQ means Web Scale", etc. SQL databases are amazing, robust examples of engineering. They are your friends and they're the appropriate choice for the vast majority of software. They are not outmoded or passe. Though I acknowledge there is a separate use case for K-V stores, I almost want to make policy preventing their use just because I know so many developers will abuse them badly and then stare back at you blankly during the semi-annual massive downtime event, muttering something like "Well, it's based on research at Google, so I'm sure there's a way to recover the data..."

toddBarkus 9y ago
I think this is a case for the return of the traditional "sysadmin" as "devops"/"SRE" is now the role of unblocking deploying a solution instead of questioning it's complexity/fitness.
- cookiecaper 9y ago
  While I agree, I also think that overt gating and approval processes create a high tension dynamic that frequently breaks down, whether it's ops v. dev, security v. dev, or others. It's easy for people to get their pride wounded, and they end up encouraged to find workarounds to the process. The simple answers to this are pretty much imaginary, unfortunately.
  - toddBarkus 9y ago
    Sure, of course. I was hoping to point out that there's an increasingly overlooked value in having someone question complexity. The "no, you don't need React" of the frontend dev or the "our data is actually relational" of the back end dev.
- rbranson 9y ago
  If your “SRE” team is only “unblocking deploying a solution” then I’m sad to say they are an operations team who has rebranded themselves to appear more relevant.
  - toddBarkus 9y ago
    That's most "SRE" -- it's a title arms race in that field between the underqualified and those that wish to convey they know how to do more than write system scripts in DSLs
EGreg 9y ago
Question, though... If your columns have types, how can you encrypt them using custom keys for each one? Is it possible? I want the keys to reside on the client and search for encrypted data. Basically single row lookups at a time.
- pandapunchpower 9y ago
  The column type would have to be the type of the encrypted value. The type of the unencrypted data could not be enforced by the DB and you would have to rely on code doing the correct thing. I am however extremely wary of doing it that way. I don't know your requirements of course.
  - EGreg 9y ago
    Here is the thing - encrypted stuff is just a weird encoded string. So I can’t really use columns normally. What I really need is just a huge table with two fields: “token”, “content” And the token is basically the primary key but encrypted with whatever encryption. You could even do foreign keys this way. Hmm I suddenly have an idea. What about a layer above the database that basically enforces foreign keys and joins in this way to support end to end encryption? The content would reference ENCRYPTED foreign keys. Only clients would decrypt stuff.
    - pandapunchpower 9y ago
      >What I really need is just a huge table with two fields: “token”, “content” Sounds more like a key value store and less like a relational database. Although you can store key value data in a relational db of course, there may be a better tool for the job.
    - JoachimSchipper 9y ago
      You'll be interested in CryptDB.
- nurettin 9y ago
  Also, how do you index that?
MrMorden 9y ago
Every fool knows that MongoDB is web scale. (Not as web scale as /dev/null, but MongoDB has a better logo.)
- reificator 9y ago
  I disagree. /dev/null's logo is way cooler. https://www.nasa.gov/sites/default/files/cygx1_ill.jpg https://www.nasa.gov/sites/default/files/cygx1_ill.jpg

toddBarkus 9y ago

I think this is a case for the return of the traditional "sysadmin" as "devops"/"SRE" is now the role of unblocking deploying a solution instead of questioning it's complexity/fitness.

cookiecaper 9y ago
While I agree, I also think that overt gating and approval processes create a high tension dynamic that frequently breaks down, whether it's ops v. dev, security v. dev, or others. It's easy for people to get their pride wounded, and they end up encouraged to find workarounds to the process. The simple answers to this are pretty much imaginary, unfortunately.
- toddBarkus 9y ago
  Sure, of course. I was hoping to point out that there's an increasingly overlooked value in having someone question complexity. The "no, you don't need React" of the frontend dev or the "our data is actually relational" of the back end dev.
rbranson 9y ago
If your “SRE” team is only “unblocking deploying a solution” then I’m sad to say they are an operations team who has rebranded themselves to appear more relevant.
- toddBarkus 9y ago
  That's most "SRE" -- it's a title arms race in that field between the underqualified and those that wish to convey they know how to do more than write system scripts in DSLs

EGreg 9y ago

Question, though... If your columns have types, how can you encrypt them using custom keys for each one? Is it possible? I want the keys to reside on the client and search for encrypted data. Basically single row lookups at a time.

pandapunchpower 9y ago
The column type would have to be the type of the encrypted value. The type of the unencrypted data could not be enforced by the DB and you would have to rely on code doing the correct thing. I am however extremely wary of doing it that way. I don't know your requirements of course.
- EGreg 9y ago
  Here is the thing - encrypted stuff is just a weird encoded string. So I can’t really use columns normally. What I really need is just a huge table with two fields: “token”, “content” And the token is basically the primary key but encrypted with whatever encryption. You could even do foreign keys this way. Hmm I suddenly have an idea. What about a layer above the database that basically enforces foreign keys and joins in this way to support end to end encryption? The content would reference ENCRYPTED foreign keys. Only clients would decrypt stuff.
  - pandapunchpower 9y ago
    >What I really need is just a huge table with two fields: “token”, “content” Sounds more like a key value store and less like a relational database. Although you can store key value data in a relational db of course, there may be a better tool for the job.
  - JoachimSchipper 9y ago
    You'll be interested in CryptDB.
nurettin 9y ago
Also, how do you index that?

MrMorden 9y ago

Every fool knows that MongoDB is web scale. (Not as web scale as /dev/null, but MongoDB has a better logo.)

reificator 9y ago
I disagree. /dev/null's logo is way cooler. https://www.nasa.gov/sites/default/files/cygx1_ill.jpg https://www.nasa.gov/sites/default/files/cygx1_ill.jpg