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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I have a lot of different databases and tables that contain user information. I would like to write a query, that would find all the necessary information. So when I use "where" clause (e.g. where Email = 'Example#example.com', or where Name = 'Mister Holmes' etc), it should bring up the results I'm looking for and search from all the related databases and tables.
My idea is to make a new view, bring all the related tables in there, and then join the necessary columns somehow. Is that possible?
Can anyone please help?
I had the same problem. I just describe my way - Because I have many different databases with different storaged infos about users, I collect all of them with INSERT and every time I am looking for WHERE SOMETHING, I am running this:
truncate target table (which is already prepared with necessary colls like NAME, LOGIN, RIGHTS, APPS, NOTES, ...)
filling target table with data from VIEWs, which are specific for each db / apps / or user groups
This two points I stored in procedure. Maybe it is not quickest way, but searching and filtering above one static table is much more safe and less consuming then searching in twenty views.
But, be aware, I you are not alone DBA and you have collegues which are playing the role of administrating sql in your area, I think, this solution is not lucky.
Or do you have standard user informations in server_principals, server_role_members, database_principals, database_permissions, schemas, ... ?
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.
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 7 years ago.
Improve this question
I write some app which analyze Instagram and Twitter posts (post serves in separate tables) and I load comments and likes too. So, it's good to use they id's as my primary key, or is better to create my id's which will not be related to third-party id.
Create your own ids in your database. In general you want these properties to be true about your primary keys:
Unique. This one the database management system will enforce for you.
Unrelated to the data they identify. This means that you shouldn't be able to calculate the primary key to any row based on the info in the row. For example, first name+last name would be a bad primary key for a People table, and credit card number would be a bad primary key for BillingInfo table.
By using the id generated by a third party service as your PK, you are unnecessarily coupling your database with their service.
Instead, there is a common pattern of using an altId column to store an extra id. You could even name the column better by calling it twitterId or something similar.
Apart from uniqueness and minimality three sensible criteria for deciding on keys are stability, simplicity and familiarity.
Above all, there is the business requirement: the need to represent the external reality with some acceptable degree of accuracy. If your database is intended to represent accurately things sourced from some given domain then you will need an identifier also sourced from that domain.
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 8 years ago.
Improve this question
A version control system compares the scripted definition of a table to the checked in state. So I guess many cvs will see column reordering of a table as a change.
Since tsql does not support to add a new column in the middle of a table and because in a relational DB the ordering should not matter, what are good practices for version control of table definitions if the column-order could change.
Sometimes you could need to redo a drop column in the middle of a table.
You should be storing scripts to setup your database in source control, not trying to have something reverse-engineer those scripts from the state of the database. Column-order then becomes a non-issue.
Specifically, I've seen two schemes that work well. In the first, each database schema update script is given a sequential number, and the database tracks which sequence number is the last applied. In the second, each database schema update script is given a UUID, and the database tracks all UUIDs that have been applied.
I would checkout the book Refactoring Databases for more details and examples of how to manage database changes.
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?