Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
One of my professor said: "If we consider that, if constraints are sometimes completely avoided and therefore not defined in some database of some project, it is only at the application level that we can manage data integrity."
In which condition can we avoid constraints on database? Please I need your help
You should ask your professor to clarify their statements, not Stack Overflow.
It's appropriate to use database constraints in many cases.
For example, consider a case where a single database is used by multiple applications. If you were to enforce data integrity in the application, then you would have to implement the data integrity rules multiple times, perhaps even in different programming languages if the client apps are written in different languages. If you don't implement the data integrity logic with the same behavior in all apps, then you might create data in one app that is invalid for the other apps.
Whereas if you implement data integrity constraints in the database, then all apps must conform to a single set of constraints. Data will be valid for all apps, and there's no chance of anomalies. This is a good thing.
There are exceptions to every rule, of course, but in general it's a good idea to implement logic in one place. This is sometimes referred to as the DRY principle of software design, i.e. Don't Repeat Yourself.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 days ago.
Improve this question
Program A is good at collecting data while Program B, in another language, is good at creating REST APIs. Is it possible to connect these two with a single database that A and B will read and write to? Performance for database operations is not really an issue in my case.
Sure this is possible. Databases typically can handle multiple connections from different programs/clients. A database does not really care which language the tool that is making the connection is written in.
Short edit:
Also most databases support "transactions". Which are used to cover that different connected clients do not break consistency of your application data while reading and writing in parallel.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Currently I am doing the aggregation & business logic (joins, revenue calculation, ect) partly in an SQL database and I am wondering if there is a general best practice for this?
With this little information available, it is hard to give you proper advice, but as a general rule of thumb, the more business logic you can implement in the database layer, the better. SQL Server is good for set-based calculations and aggregations, and that's typically what business logic would be based on.
Another advantage is that by implementing the logic in the database, your data/business logic definitions are conformed, and can be based on the business signing off on the definitions. If you'd leave that part out, when 2 different analysts will attempt to create the same business logic in Power BI, they might end up with slightly different implementations that could lead to different results. By implementing it in the back-end, both analysts would get the same output, no matter what.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We know in java, encapsulation is a process of wrapping up of code data together into a single unit or hiding the data. Can anybody let me know from whom we are hiding the data?
You are "hiding" data from users of your object that should be able to use it without needing to know about its internals.
The main reason for this is to allow you to later change these internals without breaking the code that calls into your object.
This is a technique to improve software maintainability.
Common misconception: It should definitely not be seen as a security measure (in the sense that it protects sensitive data from malicious actors that should not be allowed to gain access to it -- encapsulation does no such thing).
Data hiding is a software development technique specifically used in object-oriented programming (OOP) to hide internal object details (data members). Data hiding ensures exclusive data access to class members and protects object integrity by preventing unintended or intended changes.
Data hiding also reduces system complexity for increased robustness by limiting interdependencies between software components.
That's why Data hiding is also known as data encapsulation or information hiding.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
In a relational database it seems quite common to use soft-deletes. My pondering comes to if it is really necessary to cascade these deletes? The reason I wonder is that it seems to me that cascading a soft delete wouldn't add any additional information.
I.e. lets say we have a table MainContract and a table ServiceContract where the relation is one-to-many. Say we soft-delete the MainContract but ignore doing so to lets say three ServiceContracts that all belong to this MainContract.
If we query the DB for ServiceContracts that are not deleted, we could easily check if the MainContract owning the ServiceContract is deleted or not.
Just formulating the pondering makes me realize that the design choice here perhaps depends on whether its more likely that we will delete often or if we will need to browse a lot among historical records.
If we delete often but don't need to check the history that often, it would be better to have a simple approach to deleting (not cascading the soft delete). On the other hand, if we need to retrieve historical records often, it could be worth implementing cascading deletes so that we would need less complex queries.
However, in a relational DB, a row is often not meaningful on its own. So in any case we will need to make joins "up the tree" in order for a row to make sense. For example a ServiceContract might not provide any meaningful information without knowing what MainContract it belongs to.
Does anyone have any thoughts on this? Has anyone used any or both of these approaches?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Best practices for database logic in or out of database. Save logic in database?
What is the best practice as far as saving enumerations and other lookup data in or out of the actual database? For instance in a web store is it okay to save all of the products if you are still going to write code to put the data into and out of the tables that use this product information. What if you had user information like roles (manager, employee, etc). Would it make sense to have a lookup table for the roles or can your CRUD logic keep all of that and when a new user is added/updated the CRUD code can do that validation?
This may or may not be a community wiki that is fine if it needs to be tagged as such. I really just want more information and to know what others are doing.
EDIT: Great answers. And the consensus seems to be yes, put the constraints in the database. So my next question is what is the technical mechanism to make that happen. If I have a "roles lookup" table, and I go to add a new user. How do I say, the roles column for a new user must be one of any of the values in that lookup. I know how to do this in code but what is the SQL mechanism to do this?
The database is for data, and validation rules that enforce the integrity of that data.
To answer your specific question, yes, I would store users/roles in the database. There is no case in which I would want to have to update code in order to add users to the system.
The database is the place to enforce any logic that must be enforced to ensure data integrity. Doing that only in the application is a recipe for disaster, databases are not changed only by the application.
In part you need the lookup tables to ensure data integrity, so that values which are not part of the lookups cannot be added.
To answer your second question, look-up foreign key constraints.