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 9 years ago.
Improve this question
Why a Product object, for example, has a method called Save?
It seems to me that it is wrong for a Product saving yourself in the database.
A product should not only know only about their own responsibility?
Did I not understand the purpose of AR or the problem is not in my interpretation?
$product = new Product();
$product->name = 'sample post';
$product->price = 10;
$product->save();
The general principle of Active Record is that an instance of an object is a single row in the data store and the object is wholly responsible for the persistence of itself.
The object has a single responsibility and that is manage the persistence of itself.
Martin Fowler says it best:
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.
Related
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 1 year ago.
Improve this question
I want a unique ID for my users in my cognito user pool that can be used in databases. The sub attribute I don't think I want to use because if I ever migrate the data, those will be changed. Is it common practice to generate your own UID for users and set it as a custom attribute to your users when they are created? Is there a better way? Thanks in advance.
The most common practice is using sub as ListUser supports filtering by sub. Best way would be using both username and sub. This way, if you ever decide to migrate your userpool, you easily lookup your database and replace the sub value with new one.
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 5 years ago.
Improve this question
I am about to develop a small cms\forum. Multiple customers are going to have there own access where the customers can communicate white them.
What is best practices- to make separate SQL db to each customer's cms data or one big to contain all the customers data?
As I cannot comment, so I can only type here.
It is strange that you would like to have separate database for each customer and it seems impossible to manage multiple db for just one purpose or function. For example, how could you identify which db belong to which customer? Also, do you expect to have many resource to allocate to each customer? a db simply waste if the customer is not active.
So, I suggest you to use one db to manage all the customers data which is normal solution.
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
Let's say I have a User model and a Favorite model. I want to know how many favorites a user has.
I see that you can accomplish this in two ways.
Atomically increment a counter attribute on the user model when a favorite is created. Access using user_instance.favorite_count
Query the favorite count for the user: user_instance.favorite_set.count()
I would imagine that as the DB grows, counting becomes more expensive.
Which implementation is more scalable?
I smell some premature optimization here. Databases are extremely good at counting things. Unless you have measured and are seeing some identifiable slowness, you should not attempt to denormalize: it is difficult to get right and always at risk of getting out of sync. Go with the query; and don't forget you can use aggregation to query the counts for a queryset of users at one time.
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 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 9 years ago.
Improve this question
I am designing a database for a form which contains many select boxes and check boxes lists.
I am unsure whether to populate these lists from a table in the database or from the select html text.
as part of db design best practice which is the preferred method.
If you expect the form elements (checkboxes, lists) are likely to change often, or are conditional (based on configurable permissions/roles), then they should come from a database.
However, if they are mostly static (rarely change, not dependent on configurable permissions), then you should hard-code them. The big benefit of hard-coding them is less traffic on your DB. This will yield the best performance.