There is a regular Users (UserID, UserName, Email, Password) table which handles user registrations.
Which other tables should be added in order to handle paid membership with 2 types of paid subscriptions - Monthly and Yearly.
I think you may want to distinguish between membership details and transactions. I like the idea of adding a membership_type column (should be a tinyint column with a separate lookup table), then having a membership_expiration column as well. If you want to track each membership purchase, you can have a separate transaction table that tracks purchases. This also gives you the ability to expand to other types of purchases or transactions in the future without modifying the data model.
How about adding a membership field to the users table with one of three values- null, monthly, or yearly?
Related
Hello stackers!
Ive made a library databse, i was wondering.. i am making one-to-one relation between Copies and Loans. and one-to-many relation from Users to Loans.
Since a copy of a book only should be allowed to be assigned one loan at a time, and a loan should only be able to containt one copy of a book. if they rent other books, its multiple loans.
and a user should be able to make multiple loans, but a loan can only be assigned one specific user.
is my current relations between these three tables correct?
if not, i would love to know how to fix it, and the reason to my failed logic on the issue.
thank you in advance!
Following on from the earlier answer. If you add a User_Roles table it could/(will) prevent you from falling into the membership trap. If you assume a user with the Admin role can perform every function a user with only Basic role, then every function which requires role-checking has to have a list of acceptable roles (Admin + Basic). Many times it is more efficient to just directly assign all the different roles, i.e. Basic AND Admin, to individual users. Then when a feature requires Basic role-authorization all users can treated the same way. It's simpler in the long run.
The Loans table has a number of issues. First, there's no primary key, to be consistent with the rest of your design, it could be a LoanID. CopyID should a foreign key to the Copies table (maybe that's what is currently drawn).
One 'advanced' or modern approach to your data model could be to use a temporal table to model the Copies. Since a single copy may only be lent out 1 time, properties of the loan could be add to the Copies table. Then anytime a change is made the System Version'ed Copies table the Copies_history table would automatically keep a full accounting of all prior loan activity.
The model looks good to me. You may need to apply some in the logic to enforce a user to have only one loan with same copy of a book.
A user will be able loan a copy over and over again ? then the relationship to loan to copy 1:M
Assume a database holds some accounts and its transactions.
There would be a table Account (for simplicity it holds only an id) and a table Transaction that has columns id, account_id (foreign key), type, and value.
Now, if some money gets deposited there is no problem. account_id is chosen and type and value are defined. But what if I want to transfer money from account a to account b?
I thought about adding some kind of offset_account_id to distinguish from where to where but this is not a good solution imo.
Or do I add two transactions for each of the involved accounts? Then I first have to insert both and after update both as they need to have a circular reference to each other.
Third I thought about adding a 'transfer' table that will hold the transaction_id of the involved accounts.
My problem with the last solution nonetheless is if I delete account a I want to cascade this throughout the database, all transactions should be deleted automatically. But if I delete a then the transaction for a will disappear and the entry in the transfer table as well but the transaction of account b would still be in the database.
What is a good layout for these 'accounting' problems?
Side question: would you calculate balance at runtime or work with on insert/delete/update triggers to store the balance with the corresponding account?
I am posting an example of the tables described above. In this example, the account ID "100" has made a payment of $30 to the account ID of "123". The transaction shows up as a record in the payable table and as a record in the receivable table.
Then if the account for 100 is closed one day, you would remove the remaining balance from the account by creating a new record in the accounts payable table. If the money is transferred to a new account then a record would also be created in the accounts receivable table. This will show the history of funds moving. If you are wanting to keep track of which accounts are open or closed I would also suggest creating a table that contains all account numbers, customer names, and a column for "open/closed". That way closed accounts will be reflected in your data and you can still query based on open or closed accounts, but the history will not be deleted, which is vital for good accounting records.
I am developing a database and not how to best store this information in my sql db.
A user can buy a subscription(ie months of access) and buy credits to do certain actions on my site(each action decreases the credits down).
Do I need to make separate tables to store this as, for instance subscription may give them 3 months access but credits would be just a value with a number that would decrease or increase if they buy more.
From what you have provided until now, I would do the following:
table [customer], fields: customer_id,....
table [subscription], fields: subscription_id,customer_id,start_date,expiration_date,initial_credits
table [action], fields: date,subscription_id,credit_cost,action_type,....
Maybe add a redundunt field of current credits to subscription table if you need it fast.
I'm looking into using a company that uses Yodlee's data aggregation service and have looked some sample output that includes account information and transactions. I noticed that the unique ID and account number for the account are not housed in the table containing transactions. How do people typically go about mapping transactions to a particular count when placing multiple accounts into a relational database? It seems to me that there is no field to link the table containing account information and transaction information together.
You can use the identifier called "itemAccountId" which is a Yodlee internal id tied to uniquely identify an account. This identifier is present for an account as well as each transactions. Using this id you can segregate the transactions under same account.
Please go through the sample responses of these two APIs getItemSummaryForItem1 and executeUserSearchRequest
I'm designing a database for our CRM system and need some help with the CRM User table.
Types of users:
Admin
Sales Reps from Branch 2
Sales Reps from Branch 3
Client login
Now for this scenario would it make sense to have all users in a single table and have a table attribute called "type" to identify the type of user? OR should I have a seperate table for each type of user? Also, there will be some information sharing between the Sales reps.
Typically, I usually go with one User table with a Type associated with it. If you have additional Sales Rep attributes you want to store, create a SalesRep table with a foreign key back to the User table. Then, create a view that joins User and SalesRep, so it looks, logically, like there's just a usvSalesRep table that has all of the attributes you need for Sales Reps.
But, this depends a lot on data volume and transaction load, so additional information you can supply there is useful.
It depends on the number of users that you expect.
But usually a single table is enought.
If you'll have billions of users maybe you can do horizontal partitioning and make multiple tables.
Single table should be fine. And I disagree that the number users really have much impact on its design in this case.
Whenever possible, you should design your tables to mimick real life. Admin, Sales Rep, etc are just descriptions/attributes of who they are. Ultimately, they are all "People"... or User. So having one "User" table with "Admin", "SalesRep" as attibutes makes sense to me. Use the "Type" approach only if the user can only be one "Type". Use separate columns if they can be multiple user types. Ie. one can be a SalesRepBranch2 and SalesRepBranch3 at the same time. Might consider normalizing this even further.