Hacker News Reader

Comment by cygned | Hacker News Reader

Always wondering about constraints, relationships, entity/data reusablity and things like calculations, aggregations, ...; typical "SQL tasks" - how does one handle these in a document-oriented schemaless database like mongodb?

View on HN

Shouldn't the web app itself enforce constraints? I don't think it's reasonable to enforce password strenght for example on the DB level.

If your database knows a user's password, you are doing it wrong no matter what persistence layer you are using.

Why the DB coudln't do the hashing itself? Storing is the actual dangerous from a security perspective, plain passwords themselves just hitting your db or your web apps is fine as long you don't keep a log anywhere in plain.

You'd want to distribute the load of your slow password-hashing functions across your application servers rather than centralizing it in your single database.

Postgres bcrypt is wicked fast. You need some crazy load before it makes sense to move hashing out of the DB.

If your PW hashing function is wicked fast, you need to increase the work factor. The whole idea of a paw hash is to be comparatively slow, because that's one property that makes it harder to crack. Otherwise we could all go back to salted md5

Please change to a higher factor. PostgreSQL's default is a bit outdated and too low for modern computers.

You can have more than on database node as well.

Database constraints are intended for use in distributed systems problems (e.g. two people create accounts with the same email, buy the last item in the store, etc).

Whether you enforce password complexity in the database is a question of where your team is more comfortable working, and what the business requirements are.

Uniq indexes in MongoDB has been a thing since forever.

You can enforce complex constrains like this in `>3.0`:

    db.createCollection( "contacts",
       { validator: { $or:
          [
             { phone: { $type: "string" } },
             { email: { $regex: /@mongodb\.com$/ } },
             { status: { $in: [ "Unknown", "Incomplete" ] } }
          ]
       }
    } )

While still not having to define the rest of the schema that you don't want too. It feels more flexible.

More flexible than what? You can do the same in Postgres, just use a single JSON field (which lets you store any structure) and add constraints on the JSON key(s).

You can do things like this in Postgres as well - my point was that the database are designed to solve distributed systems problems, so your database of choice is a good place to solve those problems.

I couldn't make a universal statement about where the constraints you're talking about should go without knowing the business rules for the application.

What happens when your platform grows and a different app needs to use the same data? Enforce constraints in two places instead of one?

You still need your DB to be correctly sharded plus app constrains correctly distributed. It still more complicated than to enforce only in one place.

You are right, password strength is an example for an application layer constraint.

However, by constraints I was more talking about things like "these properties need to be unique", "this column here must reference that column over there", "this column's values must be in this set" and so on.

I know I could enforce these things in the application layer, but I don't think that's feasible.

Got you. Uniq indexes are a thing in MongoDB as well, but I can see that just another schema-like behavior and doesn't fit what I was saying earlier.

If your constraints are about more than one row (e.g uniqueness, non overlapping ranges, foreign keys) it's very hard to do so clientside in a concurrent setup - unless you're ok with very coarse locking.

Edit: Typo

Via corollary with Greenspun's tenth law, or not at all.

Thanks, didn't knew about that.

Reply on news.ycombinator.com