Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
12

It depends on what kind of application system you are building: if you are creating an application-centric system which contains just one main application, with a dedicated database specifically for this application, and ideally one team responsible for evolving application and database side-by-side, you can keep all validation logic and also audit logic ...


3

I think the question is about responsibility for quality of data. The answer depends on how you see the system. If you see the database as an independent, distinct, and autonomous service separate from the application, then the database is responsible for ensuring the consistency and quality of the data it contains. Essentially because that database could ...


3

Q: For the functionalities that are similar for the mobile and web admin, how can avoid duplicating the code? Essentially, encapsulating the domain and the business logic in their own components and modules so the web layer acts as a driver or facade. This is what web interfaces are meant to be, an extension which allows our business expand up to the WWW. ...


2

It's very unlikely that you could restrict the access to a single table in a real application, so you would have to specify all the required tables and maintain that list. It's a somewhat normal approach to limit things to the database user on the larger scale, such as using different roles for reporting, normal users, admins etc. depending on which layers ...


2

No, you should never use triggers to do validation. The database is only responsible for its own integrity. Any user facing validation should be performed by your application. Databases perform three levels of validation for integrity. The first one is field level validation. A field can be required, if there is no value (null) it is an error. It can also ...


2

Shall we store the request as is with Body, URL, and Headers in a blob/text in db so it is easier for the Scheduled Service to Resend it, Baaad, bad idea. Consider things like authentication tokens that a) you will need to store securely and b) tend to expire. Then some services (e.g. AWS SES) require you to sign each request so they're only valid in-...


1

What I got from talking with Robert : Why no row self-referencing ? in the real life we are modelising in the DB, there is no parent to the header : by lemma "we want DB to match closely real life", we want null for parent_id. There is no parent => no parent_id. That's the main argument. Issue with nullable parent_id : the parent_id == id case must ...


1

Because the question is about if we really need triggers for relational databases here are some other use cases where to use triggers: For auditing as described in the other answers. Auditing in the wider sense: if a database entry is changed a trigger can record the event for asychroneous post processing, e.g. nightly exports to another application. ...


1

Audit is a classic example of the use of triggers effectively. I've found some errors made by the tester (moving a client from one level of service to another) thanks to an Audit table which was implemented by triggers. I highly recommend using triggers for audit. Validation could be done in the front end level, but I've seen weird errors in database that ...


1

If the order of the question in a questionnaire is fixed, then approach 1 is the way to go. It is not normal that the update is very slow, whatever the size of your questionnaires. But instead of ruining your relational schema because of performance problems, you'd better solve the latter ones: so make sure that that you have an index on the ...


1

Doing that for a typical B-tree index is probably not going to be terribly helpful and potentially harmful due to the extremely low cardinality in the deleted_at column (it can only ever be true or false). In most cases you would never want to query on this column and almost always would want to filter out records where this is true (deleted). A ...


1

You're toying with the idea of working immutably. Nothing is ever destroyed. You just change things by adding new things. This non-destructive approach is disorienting to people used to the CRUD mentality. But so long as you have the storage capacity it works. Just look at wikipedia. Changes all the time and nothing is ever really lost. With this ...


1

While the OP briefly touched on the notion of using a Linked-List to store sort-order, it has a lot of advantages for cases where items will be reordered frequently. I have seen people using a self-reference to refer to the previous (or next) value, but again, it seems like you would have to update a whole lot of other items in the list. The thing is - ...


Only top voted, non community-wiki answers of a minimum length are eligible