4 ms·
Always wondering about constraints, relationships, entity/data reusablity and things like calculations, aggregations, ...; typical "SQL tasks" - how does one ha
by cygned 9y ago
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?
- throwanem 9y agoVia corollary with Greenspun's tenth law, or not at all.
- cygned 9y agoThanks, didn't knew about that.
- hartator 9y agoShouldn't the web app itself enforce constraints? I don't think it's reasonable to enforce password strenght for example on the DB level.
- wedowhatwedo 9y agoIf your database knows a user's password, you are doing it wrong no matter what persistence layer you are using.
- hartator 9y agoWhy 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.
- danneu 9y agoYou'd want to distribute the load of your slow password-hashing functions across your application servers rather than centralizing it in your single database.
- icebraining 9y agoYou can have more than on database node as well.
- rpedela 9y agoPostgres bcrypt is wicked fast. You need some crazy load before it makes sense to move hashing out of the DB.
- Xylakant 9y agoIf 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
- jeltz 9y agoPlease change to a higher factor. PostgreSQL's default is a bit outdated and too low for modern computers.
- deleted 9y ago[deleted]
- cygned 9y agoYou 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.
- hartator 9y agoGot 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.
- deleted 9y ago[deleted]
- bsg75 9y agoWhat happens when your platform grows and a different app needs to use the same data? Enforce constraints in two places instead of one?
- hartator 9y agoYou still need your DB to be correctly sharded plus app constrains correctly distributed. It still more complicated than to enforce only in one place.
- anarazel 9y agoIf 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
- garysieling 9y agoDatabase 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.
- hartator 9y agoUniq 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.
- icebraining 9y agoMore 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).
- garysieling 9y agoYou 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.