I have a database modeling related problem and would like you guys to give me sugestions how could i solve it.
I need to sell "virtual services". I made some tables: Clients, Services, Order, OrderLine. So a Order can contains multiples services. Each service has an "contract time". If i order a service it is valid for 30 days then i need to order it again if i want to continue using it. if i order a service for 30 days and 10 days has passed i still have 20 days. If i order it again i'll have 50 days.
How can i model the database to control this?
Looks like you just need to use Orderline and have the start date and end date valid for that particular order.
So you will have one entry for every renewal. And this table should have FKs to Service and Order.
Related
I am trying to create a business hours application using DynamoDB.
I saw lots of examples and schema designs for different databases but just can't find the right table design for DynamoDB.
Here are my requirements:
every business should have default working hours (Monday 08:00 - 14:00, 16:00 - 20:00) and special events (26/11/2020 shop is closed / opened between 10:00 - 14:00 due to Thanksgiving)
every day can have multiple work durations (08:00 - 14:00, 16:00 - 20:00)
Those are the operations I need to allow:
Create / edit working hours for each business (including special events)
Check whether a business (or a list of businesses) are open right now - by providing a list of business ids.
Get business (or list of businesses) working hours between 2 dates (for example 23/04/2020 - 25/04/2020) by providing a list of business ids and date range for each id
What I've tried:
Defined a table where business id is the partition key (HASH) and special dates / day of week is the sort key (RANGE).
The problem with this approach is that I cannot query by multiple business hours unless I use the scan api which is not recommended due to expensive operations.
Please advice what kind of table design I should use for this application.
You probably need to first construct your overarching logic outside of DynamoDB, do decide if a business is working or not, and only use quarries in Dynamo for a subset of that logic.
Lets say though we use DynamoDB for querying in regards to normal working hours, and not include logic like holidays and special cases, you can use that to filter after you access Dynamo. You can't construct one query in Dynamo to answer all your questions that is more like what you can do in SQL.
So lets say we have a Table/Subset of values which relate to the normal working day. So you have something like this:
Partition Key (PK): business, Range Key (RK): dayOfWeek, and attributes, opens & closes.
We can then create 2 GSIs:
PK dayOfWeek RK opens
PK dayOfWeek RK closes
Now we can do two queries if a store is open between 3-4pm on Monday:
PK == MONDAY & opens < 2 pm
PK == MONDAY & closes > 4 pm
And collect only the values which appear in both queries.
Obviously though, having a PK of day, is probably not a great idea, as you will only have 7 partitions. So what do you do? Well you probably have more criteria in your query than simply day, for example, the type of store, the city the store is located it, etc. That would mean then you would have a PK of something like: city-category-dayOfWeek.
Similarly on the sorting side, you might want higher rated stores to be the first option, so you might have something like: {rating}-{open} & {rating}-{closes}.
You will just have to get creative, firstly layout all the queries you have before you design your tables. I really like this video on table design, it's terrific.
I am working on a data warehouse solution, and I am trying to build a dimensional model from tables held in a SQL Server database. Some of the tables include but aren't limited to Customer, Customer Payments, Customer Address, etc.
All these tables in the DB have some fields that are repeated multiple times across each table i.e. Record update date, record creatuin date, active flag, closed flag and a few others. These tables all relate to the Customer in some way, but the tables can be updated independently.
I am in the process of building out a dimension(s) on the back of these tables, but I am struggling to see how best to deal with these repeated fields in an elegant way, as they are all used.
I'll appreciate any guidance from people who have experience with scenarios like this, as I ammjust starting out
If more details are needed, I am happy to provide
Thanks
Before you even consider how to include them, ask if those metadata fields even need to be in your dimensional model? If no one will use the Customer Payment Update Date (vs Created Date or Payment Date), don't bring it into your model. If the customer model includes the current address, you won't need the CustomerAddress.Active flag included as well. You don't need every OLTP field in your model.
Make notes about how you talk about the fields in conversation. How do you identify the current customer address? Check the CurrentAddress flag (CustomerAddress.IsActive). When was the Customer's payment? Check the Customer Payment Date (CustomerPayment.PaymentDate or possibly CustomerPayment.CreatedDate). Try to describe them in common language terms. This will provide the best success in making your model discoverable by your users and intuitive to use.
Naming the columns in the model and source as similar as possible will also help with maintenance and troubleshooting.
Also, make sure you delineate the entities properly. A customer payment would likely be in a separate dimension from the customer. The current address may be in customer, but if there is any value to historical address details, it may make sense to put it into its own dimension, with the Active flag as well.
I have a customer table and services table in SQL Server 2012. A customer can avail services if he wants, laundry, housekeeping, food.
In Customer table I have kept services as a multivalued attribute. When I resolve it, I make an associative entity for services table where I put C_id*, Service and Price.
My question is what query to write a subquery at time of table generation in of customer to enter a particular price for a service availed? Basically how to handle this? I would later use these to create an invoice when total bill calculated.
Likewise, I have member types as well. If a member is lifetime then allow 20 percent discount and seasonal 10 percent.
How to handle it? Subqueries?
Code snippets would help.
I am working on a multiple properties booking system and making me headache about the best practice schema design. Assume the site hosts for example 5000 properties where each of it is maintained by one user. Each property has a booking calendar. My current implementation is a two-table-system with one table for the available dates and the other for the unavailable dates, with a granularity of 1 day each.
property_dates_available (property_id, date);
property_dates_booked (property_id, date);
However, i feel unsure if this is a good solution. In another question i read about a single table solution with both states represented. But i wonder if it is a good idea to mix them up. Also, should the booking calendar be mapped for a full year with all its 365 days per year into the database table or was it better to map only the days a property is available for booking? I think of the dramatically increasing number of rows every year. Also i think of searching the database lately for available properties and am not sure if looking through 5000 * 365 rows might be a bad idea compared to i.e. only 5000 * av. 100 rows.
What would you generally recommend? Is this aspect ignorable? How to best practice implement this?
I don't see why you need a separate table for available dates. If you have a table for booked dates (property_id, date), then you can easily query this table to find out which properties are available for a given date
select properties.property_name
from properties where not exists
(select 1 from property_dates_booked
where properties.property_id = property_dates_booked
and property_dates_booked.date = :date)
:date being a parameter to the query
Only enter actual bookings into the property_dates_booked table (it would be easier to rename the table 'bookings'). If a property is not available for certain dates because of maintenance, then enter a booking for those dates where the customer is 'special' (maybe the 'customer' has a negative id).
I'm new to creating cubes, so please be patient.
Here's an example of my data
I have multiple companies, each company has multiple stores.
Sales are each linked to a particular company, with a particular store on a particular date.
ex:5 sales took place for Company A, Store 1, on 5/19/2011
Returns are linked to a particular company on a particular date.
ex: 3 returns took place for Company A on 3/11/2012
Sometimes my users want to see a list of stores, the date, and how many returns took place, and how many sales.
Sometimes they want to see a list of companies, the specific stores, and the number of sales.
I have a table that stores
COMPANY - DATE - STORE- SALES - RETURNS
I end up having the value for returns repeated for each store under a particular COMPANY - DATE pair.
so if I'm writing a query, and I want to find out returns, I just do a
select distinct company, date, returns from mytable
but I am not sure how to this into a cube (using SS BI and Visual Studio).
(I've only made a couple of cubes so far)
Thanks! (also, feel free to point me at appropriate references)
It sounds like Company is an attribute of the Store and should be in the Store dimension rather than the fact table. There may have to be a transformation on returns to convert the Company to a store.
Am I missing anything?