I'm really stuck on the best way to implement this database.
Here is my problem: The database is to store information on wedding photography clients.
A user can sign up to my site, enter the details of their wedding and get their own "wedding profile page". They can do this without having to have us shoot their wedding.
At any point the user can book a meetup, wedding, or engagement shoot. The website will check if we are available. (weddings take preference over meetups so a client that wants to book a wedding on a day we have a meetup, the meetup will be flagged for a reschedule)
We must also be able to book days off. On these days a wedding/meetup/engagement shoot can not be booked.
engagement shoots cost and upfront fee. With weddings, a deposit is due within 14 days or the date is freed up again. Meetups are free.
I am so stuck with how to implement this system. I just keep going round in circles, the best way I can think is to have a "dates" table, that links all the other tables but I'm sure this is not the most efficient way.
I think what is putting me off is the fact that there can be multiple weddings on the same day (for people who just want a wedding profile), but only one BOOKED wedding per day.
So have I got this completely wrong? or do I store all appointments in one table and use a "type of appointment" table.
SO SO Stuck, I hope you can help me!
P.S. I have missed most fields out to make it simpler to understand.
Keep it simple to begin with. You've identified many of the nouns that should correspond to entities:
USERS
WEDDINGS
ENGAGEMENT_SHOOTS
MEETUPS
UNAVAILABLE
DATES
PAYMENTS
I'd suggest that WEDDINGS, ENGAGEMENT_SHOOTS, MEETUPS and UNAVAILABLE are all type of bookings. You could have just:
USERS
BOOKINGS - this has a date and perhaps a status
BOOKING_TYPE (wedding, meetup, engagement_shoots, unavailable)
PAYMENTS
You may wish to package up all on the things a use has bought relating to a single wedding into a TRANSACTION entity etc which will allow a single payment to be mapped to multiple bookings. When one of your staff isn't available they could have a booking of type holiday etc.
There may be 2 types of USERS - your photography staff who are assigned to a booking and your customer.
Based on the status of the booking, eg. CONFIRMED, PENDING, COMPLETED and the date your business logic could send out payment demands, followups etc.
Create a simple model and start adding data you will soon see the gaps and issues if any. You should have test cases up front to ensure that the data model supports all the scenarios for your application, best to do this with a set of use cases.
Related
I've been studying dynamodb docs for the last 2 weeks and made my database design but I'm stuck with one thing although I think I have a quite good understanding of this db engine so far, I cannot crack down the following problem.
Let's say (for simplicity) I have a Spotify like service with the following records in the table:
User record:
PK: USR_#
SK: User
data: name (doesn't really matter)
Song record:
PK: SNG_#
SK: Song
data: title
Listened record
PK: USR_#
SK: SNG_#
data: date listened
Listened record is a record in a database that indicates that a user have listened to a specific song.
Imagine we have thousands of users and thousands of records in the table.
Now, the requirement (access pattern if you will) is to suggest to users songs that they have never listened to.
I spent hours looking into dynamodb docs, but it seems to me that it's impossible to model.
How can I query songs, that a user never listened to?
I could think of some really inefficient ways to model it by adding a list of users to a Song record which is obviously ridiculous in my opinion because I would have to scan all the Songs and filter by attribute where the USR_# does not exist.
Is there any more efficient pattern to approach this problem?
Keep all the listened SNG# of the logged in user from the Listened record table and keep it in memory(Say HashMap). Write a logic to randomly pick the SNG_# from the Song record which is not in the in memory MAP and suggest that song.
I believe this can be better handled at the app layer than the DB layer. As Dynamodb doesn't have joins, you need to build a join like logic in the app.
I am designing a database for a sales company having a complex workflow. The flow starts at Sales Officer, then go to Team Lead and finally Manager. Before approving a proposal, manager will send it to the Division Business Analyst. After getting remarks from dba, he may send the proposal back to sales officer for modification in the proposal. The manager may also reject the proposal. If satisfied, manager will forward it to Director, Sales. The tables designed so far as follows:-
Table: ProposalBasicData
Id, Title, ProposalDate, Scope, Objective
Table: ProposalState
Id, Name
(Values - Forwarded , Approved , Returned , Rejected)
Table: UserType
Id, Name
(Values - SalesOfficer, TeamLead, Manager , DBA, DirectorSales)
Table: WorkFlow
Id, StartUserType, NextUserType, StateId, IsActive
Table: RequestAction
Id, ProposalId, WorkFlowId, UserId, ActionDate
Please suggest regarding the design.
There are many questions raised by such problems. Ex:
in your tables, Workflow defines transitions from state to state as changing the assignment from one user to the next.
this can be an issue. Lets say the user is sick, leaving, on vacation, ... Then your flow is blocked.
It does not allow for the group concept either.
others (like I) would define a transitions table. StartState, NextState.
The workflow would be a list of transitions.
Each transition requires the user to be of a certain type. Or from a user management point of view, have a certain role, or be member of a group.
If your workflow is fixed and is not subject to change, your method could be ok. But if the workflow is flexible or might be changed / adapted, you should go with something more flexible.
The type of setup you are talking about make me think of the Jira software (form Atlassian), where you define tickets, with status, workflows and users. Is it possible for you to use (i.e purchasse or OpenSource) a workflow management tool? It might be cheaper in the long run than building one.
Your model will potentially be expanded to include:
clients. Which client is the proposal for?
who is the sales representative or account manager who is responsible for auditing the workflow and moving it forward?
link to other systems: how does it link to purchasing, accounts receivable, ...
All this to day, this requires an in-depth analysis which is hard to do on a medium such as this (SO).
EDIT: 20181004
I added the following model following your comment. I decided to put the workflow(s) in the database:
Notes (tables in alphabetical order):
Employee
Each employee can be linked to n number of EmployeeRole via the Employee_has_EmployeeRole table.
Proposal
An Employee is linked as the Sales Officer, since he initiates a proposal.
A workflow is linked since many workflows could exist for different proposals.
Transition
Linked to State twice. The start state and the end state.
An EmployeeRole is linked, to identify which role an employee must have to perform this transition.
Enforcing that will be done by the application.
Workrlow_has_Transition
Links Transitions to Workflows.
The Employee who completed the transition is recorded here.
The date it was done is also kept here.
The OrderInWorkflow is just a number that allows you to order Workflow_has_Transition entries.
The application will have to make sure a Transition is not done before the others of lower order are done (i.e. DoneDate is null).
It will also validate that the Employee trying to complete it has the proper EmployeeRole.
Now, the employee group concept. You can say that a group are employees with the same EmployeeRole. Therefore, when a notification needs to be sent by your application, send it to all users with the required role for the Transition. This avoids you having to create an EmployeeGroup table, which links employees together.
Application scenarios:
- Start a Proposal
- Verify that the user trying to start a new one has the role "Sales Officer"
- Collect basic information.
- Link the Sales Officer to it (current user).
- Link a Workflow to it. Only propose the workflows which have at least 1 Workflow_has_Transition.
- Send a notification to the Employee(s) which have the EmployeeRole for the first Workflow_has_Transition for this new Workflow.
- These employees receive a notification.
- Progressing through the workflow
- An employee receives a notification about a Proposal and it's "todo" Transition.
- Employee views Proposal and Workflow (use the OrderInWorkflow to ORDER BY Transitions).
- Employee approves if he has the proper EmployeeRole, fill DoneBy_idEmployee and DoneDate.
While going through your application scenarios, you will find gaps or missing items.
Ex.1 do you want to record the rejection of a Transition? How would that be handled then? You send a notification to the employees with the role for that Transition to review it?
Ex.2 do you want to keep the complete history of the proposal? Ex. it Transition X is rejected twice, but approved the third time around.
There are many scenarios like this which will show the weaknesses of your model, which you fix as you complete this analysis. Now it is not perfect, I did not put a lot of time on it. But it is a starting point and illustrates my idea.
I would suggest you structure some where along this
ProposalBasicData {PBID,Title, ProposalDate,Scope,Objective}
ProposalState {PSID,Name}
UserType {UTID,Name}
User {UID,Name,UTID(Usertype UTID FK) }
Request{ RID, StartUID, StartDate ,PSID, IsActive }
RequestAction {AID,RID, RequesterUID, ReceiverUID, Date, Comments, IsCompleted }
as I think there could be multiple users of the same type, more over you would want to have comments on why it a RequestAction was rejected, A requester would make a requestAction to a receiver and if its completed it would show in the system make life easier when handling multiple requestActions of the same Request.
Hope this helps but i suggest you make a flow chart and look at what are all the possible use cases.
Below is the current design of school fees and payment I have created.
I'm just a little stuck right now because I can't model the payment/transaction table. Also, I would like to know your thoughts and comments with my current design. This is the first time I'll create a database for fees and payments.
Main tables of my concern are schoolyearfee_lt , student_fee_lt and Payment
I'm thinking of using the Payment table to store the sum of all fees on which will be divided to whatever payment term was chosen (monthly,quarterly,annual,cash).
Let's say for instance, Monthly was chosen as payment plan.
amountToPayPerMonth = (sumOfAllAssignedFees / paymentterm) - downpayment
Where 11 inserts of the amountToPayPerMonth to payment table will be executed and 1 downpayment. 11+1 = 12 months
How do I mark it as paid? Should I use another Transaction table?
Is this a good design? Any thoughts or advice?
Thank you.
some (personal) thoughts about your design and question.
1- schoolyearfee_lt. It seems 1-to-n with fee_mt. If i well understand the same fee can be applied for several shoolyears, category etc, but the amount for a fee does not change. It means, for example, that every year in which fee amounts change i should create -at least- a new fee and some shoolyearfee. I believe something can be reviewed here. I could from example move some of its fields (schoolyear?) to the fee_mt table, and/or i could move the amount from fee_mt to schoolyearfee_lt. There are also some more possibilities, i.e. making a table fee_years_lt, where storing year and amount (and maybe other factors which change the fees) and so on. Maybe you could make some of these changes, maybe none, depends on your design and requirements. The questions may be: is the amount changing by year (i believe yes), gradelevel, feetype, feecategory or not ? You want a master fee that you want applicable forever or your fees are recreated each year from scratch ?
2- Payment. I would call it exactly with its meaning: payment_plan. I would add a field paid, a field payment_date and a field schoolyear (in current design).
3- Student_fee_lt and schoolyear. In the current design you better add the year too. Depending on the mode the fee_mt is managed (see above) i would put it in the PK too. Moving the year to the fee_mt, you don't need. Is student_fee_lt really needed (it seems the result of a query + the field date_effective) ?
4- Payment Formula. The downpayment and consequently the formula is a little nclear to me. Is it a kind of discount for every payment you do or is it a fixed amount ? In the latter you should review your formula. Why 11 payments ?
5- Choosen Payment Plan storage. I would have a table where storing the chosen payment plan by the student (and some other data), this should not be student_fee_lt, because it stores the single fees assigned for each student.
I want to create an application which allows Users to budget money they already have into various categories for a given month.
I've already modeled and prototyped handling the data which is tangible; e.g. Bank Accounts, Transactions, Transfers. The problem I am running into is with relating this "real" data (the stuff sitting in your bank, or in your pocket, or on your bank statement) with these fake notions of Budgets (or, as I like to consider them, envelopes).
Here's a quick list of requirements that I've thrown together:
User can manage their Financial Accounts
User can manage their Financial Transactions
User can associate each Transaction with a Financial Account
User can transfer money between Accounts
User can assign available money to a given Budget Category, per-month
User can modify existing Monthly Budget Categories (reduce or increase)
User can view the amount of money remaining for a given Monthly Budget Category
User can view amount of money available to Budget (may be negative)
Money remaining from a Budget Category can carry over to the next month
User can view their Financial Account totals (should not be affected by budget)
User can create Budget Categories as goals that could eventually be closed (e.g. Savings for a new car)
(Probably some other Use-Cases I am forgetting)
The use-cases in bold are the ones I am struggling with.
I toyed with the idea of having a "MonthlyBudget" object, which each transaction could be related to; but this seemed overly-complicated to implement in a database because I'd have to implement a date-range instead of a simple date.
I played with the idea of treating these Monthly Budget Categories as Accounts, and one would simply perform Transfers to them; but then there'd be no way for the User to cross-check their bank statement with the data in the system.
I played with the idea of "fake money" in which Budgets would somehow make use of, thereby separating "real money" and "budget money" -- but couldn't think this through logically.
I'm a bit at a loss on finding a clear and concise way of implementing this, specifically using a relational-database for storage. If anyone has any suggestions or idea, I'd be very appreciative.
The reason why people experience frustration with the budget envelope method is that it ties budget allocations to specific money actually present, whereas money is fungible and can count against the budget, whatever the source. Moreover, when you write a check or swipe your credit card, it may be for a purchase that includes multiple budget items.
A typical commercial budget data model sets up budgets in periods (monthly in your definition) and budget items with amounts. When funds are disbursed, the payment is applied to the appropriate budget item(s), partially or in full. To find out what you have left to spend in your budget, subtract all the applied payments.
If this is for personal finance, people are on a cash basis. However, the same principles apply. So you would have a grocery bill of $220. Maybe $150 of that was for regular food we eat all week, and the other $70 was for a Christmas party. When you come home and enter the grocery bill into the computer, you would want options:
Apply the whole $220 to grocery, because it has to be made up somewhere;
Apply the $150 to grocery and apply the $70 to seasonal entertainment;
Apply the $150 to grocery and put the $70 aside, because I haven't set up a seasonal entertainment budget yet. We don't want to make the user stop the whole process to create more budgets in order to enter the grocery bill, or soon s/he won't be entering the grocery bill faithfully any more because it is just too much work.
Each reservation contains names of the guests & a company name.
Now, the guests may/may not belong in a company. (a booking may have a company as null)
Currently, I have:
Booking_table (booking_id, guest_id, company_id)
Guest_table (guest_id, guest_name)
Company_table (company_id, company_name)
Guest_booking_history (guest_id, booking_id)
Company_booking_history (company_id, booking_id)
Am I doing this right? Any suggestions in designing the database?
An alternative would be:
Booking_table (booking_id, guest_names, company_id)
Company_table (company_id, company_name)
It's mostly good, but I'd consider adding the company to the guest, and maybe remove the company from the booking table. Something like:
Booking_table (booking_id, guest_id)
Guest_table (guest_id, guest_name, company_id)
Other than that, I think your database is missing a lot of important data - dates, customer info, etc, but that's a whole other issue fully dependent on exactly what you want to achieve with the database and software.
Seems like it would be usefull to have the booking dates, and booking needs likely needs to be linked to a table of rooms.
It all depends on what data you want to keep and track ;)
Other then that, if this is homework mark it as that.