In ioS 5, arc
The scenario that I've to implement in core data is that a product can be connected to several promotions, e.g. simple, multi buy etc. the type of the promotion determines the field values that are persisted eg. simple promotion needs to store the quantity, promoted price and the multi buy needs to store a description that says buy 2 at $6 but get 1 for $4 for eg. I need to persist these in core data.. what is the best design pattern to model these?
Thanks in advance for your help on this.
Figure out what data you need to describe a promotion. For example, you might need: 1) description, 2) discount, 3) start date, 4) end date. Create a Promotion entity that stores all that stuff.
Create a relationship between your Promotion entity and your Product entity. You'll probably want a many-to-many relationship here, since a given promo can apply to several products, and a given product can have multiple promotions.
There is no step 3.
Related
I am in the process of designing this E-R diagram for a shop of which I have shown part of below (the rest is not relevant). See the link please:
E-R diagram
The issue that I have is that the shop only sells two items, Socks and Shoes.
Have I correctly detailed this in my diagram? I'm not sure if my cardinalities and/or my design is correct. A customer has to buy at least one of these items for the order to exist (but has the liberty to buy any number).
The Shoe and Sock entities would have their respective ID attribute, and I am planning to translate to a relational schema like this:
(I forgot to add to my diagram the ORDER_CONTAINS relationship to have an attribute called "Quantity". )
Table: Order_Contains
ORDER_ID | SHOEID | SOCKID | QTY
primary key | FK, could be null |FK, could be null | INT
This clearly won't work since the Qty would be meaningless. Is there a way I can reduce the products to just two products and make all this work?
Having two one-to-many relationships combined into one with nullable fields is a poor design. How would you record an order containing both shoes and socks - a row per shoe with SOCKID set to NULL and vice-versa for socks, or would you combine rows? In the former case the meaning of QTY is clear though it depends on the contents of SHOEID/SOCKID fields, but what would the QTY mean in the latter case? How would you deal with rows where both SHOEID and SOCKID are NULL and the QTY is positive? Keep in mind Murphy's law of databases - if it can be recorded it will be. Worse, your primary key (ORDER_ID) will prevent you from recording more than one row, so a customer couldn't buy more than one (pair of) socks or shoes.
A better design would be to have two separate relations:
Order_Socks (ORDER_ID PK/FK, SOCKID PK/FK, QTY)
Order_Shoes (ORDER_ID PK/FK, SHOEID PK/FK, QTY)
With this, there's only one way to record the contents of an order and it's unambiguous.
You have not explained very well the context here. I'll try to explain from what I understand, and give you some hints.
Do your shop only and always (forever) sell 2 products? Do the details of these products (color, model, weight, width, etc...) need to be persisted in the database? If yes, then we have two entities in the model, SOCKS and SHOES. Each entity has its own properties. A purchase or a order is usually seen as an event on the ERD. If your customers always buys (or order) socks with shoes, then there will always be a link between three entities:
CLIENTS --- SHOES --- SOCKS
This connection / association / relationship is an event, and this would be the purchase (or order).
If a customer can buy separate shoes and socks, then socks and shoes are subtypes of a super entity, called PRODUCTS, and a purchase is an event between CUSTOMERS and PRODUCTS. Here in this case we have a partitioning relationship.
If however, your customers buy separate products, and your store will not sell forever only 2 products, and details of the products are not always the same and will not be saved as columns in a table, then the case is another.
Shoes and socks are considered products, as well as other items that can be considered in future. Thus, we have records/rows in a PRODUCTS table.
When a customer places an order (or a purchase), he (she) is acquiring products. There is a strong link between customers and products here, again usually an event, which would be the purchase (or a order).
I do not know if you do it, but before thinking of start a diagram, type the problem context in a paper or a document. Show all details present in the situation.
The entities are seen when they have properties. If you need to save the name of a customer, the customer's eye color, the customer's e-mail, and so on, then you will have certainly a CUSTOMER entity.
If you see entities relate in some way, then you have a relationship, and you should ask yourself what kind of relationship these entities form. In your case of products and customers, we have a purchasing relationship there between. The established relationship is a purchase (or an order, you call it). One customer can buy various products, and one product (not on the same shelf, is the type, model) can be purchased for several customers, thus, we have a Many-To-Many relationship.
The relationship created changes according to the context. Whatever, we'll invent something crazy here as examples. Say we have customers and products. Say you want to persist a situation where customers lick Products (something really crazy, just for you to see how the context says the relationship).
There would be an intimate connection between customers and products entities (really close... I think...). In this case, the relationship represents a history of customers licking products. This would generate an EVENT. In this event you could put properties such as the date, the amount of times a customer licked a proper product, the weather, the time, the traffic light color on the street, etc., only what you need to persist according to your context, your needs.
Remember that for N-N relationships created, we need to see if new entities (out of relationship) will emerge. This usually happens when you are decomposing the conceptual model to the logical model. Probably, product orders will generate not one but two entities: The ORDER and the products of orders. It is within the products of orders that you place the list of products ordered from each customer, and the quantity.
I would like to present various materials to study ERD, but unfortunately they are all in Portuguese. I hope I have helped you in some way. If you want to be more specific about your problem, I think I can really help you best. Anything, please ask.
I'm building a Ruby on Rails App for a business and will be utilizing an ActiveRecord database. My question really has to do with Database Architecture and really the best way I should organize all the different tables and models within my app. So the App I'm building is going to have a database of orders for an ECommerce Business that sells products through 2 different channels, a subscription service where they pick the products and sell it for a fixed monthly fee and a traditional ECommerce channel, where customers pay for their products directly. So essentially while all of these would be classified as the Order model, there are two types of Orders: Subscription Order and Regular Order.
So initially I thought I would classify all this activity in my Orders Table and include a field 'Type' that would indicate whether it is a subscription order or a regular order. My issue is that there are a bunch of fields that I would need that would be specific to each type. For instance, transaction_id, batch_id and sub_id are all fields that would only be present if that order type was a subscription, and conversely would be absent if the order type was regular.
My question is, would it be in my best interest to just create two separate tables, one for subscription orders and one for regular orders? Or is there a way that fields could only appear conditional on what the Type field is? I would hate to see so many Nil values, for instance, if the order type was a regular order.
Sorry this question isn't as technical as it is just pertaining to best practice and organization.
Thanks,
Sunny
What you've described is a pattern called Single Table Inheritance — aka, having one table store data for different types of objects with different behavior.
Generally, people will tell you not to do it, since it leads to a lot of empty fields in your database which will hurt performance long term. It also just looks gross.
You should probably instead store the data in separate tables. If you want to get fancy, you can try to implement Class Table Inheritance, in which there are actually separate but connected table for each of the child classes. This isn't supported natively by ActiveRecord. This gem and this gem might be able to help you, but I've never used either, so I can't give you a firm recommendation.
I would keep all of my orders in one table. You could create a second table for "subscription order information" that would only contain the columns transaction_id, batch_id and sub_id as well as a primary key to link it back to the main orders table. You would still want to include an order type column in the main database though to make it a little easier when debugging.
Assuming you're using Postgres, I might lean towards an Hstore for that.
Some reading:
http://www.devmynd.com/blog/2013-3-single-table-inheritance-hstore-lovely-combination
https://github.com/devmynd/hstore_accessor
Make an integer column called order_type.
In the model do:
SUBSCRIPTION = 0
ONLINE = 1
...
It'll query better than strings and whenever you want to call one you do Order:SUBSCRIPTION.
Make two+ other tables with a foreign key equal to whatever the ID of the corresponding row in orders.
Now you can keep all shared data in the orders table, for easy querying, and all unique data in the other tables so you don't have bloated models.
I build a Rails 4 application with a Redis Datastore.
The model has some complex objects to store products and some associations to them.
This application is used by up to 50 customers.
Every customer has his own products (up to 2000 products)
Now... I don´t wanna mix up the products in one redis object.
Is it a good idea to create an object per customer so redis does not have one big product object for all customers?
I think about something like a prefix on a customer specific token.
The object for an customer specific product object can called like 'amazon_products'
What do you think? Any suggestions?
If you want to do operations on these products based on the customer they belong to then yes, I would create one object per customer. I would also use a prefix like pr:<user-id> (ie. pr:123 would contain all the objects for customer with id 123).
However it depends on the ways you will ask for the data and the operations that you will perform on them.
I'll phrase the question in the context of my application but I think it does have a wider scope generally for configuration. My application allows companies to track absences and holidays for its employees. One of the benefits is that it will automatically increase a person's holiday entitlement based on rules set by the employer. The intention is for the company to choose between:
A) automatically increase an employee's entitlement by a set number of days every year e.g. on 1 January each year, holiday entitlement increases by 1 day; or
B) an employee's entitlement increases based on length of service e.g. after 2 years' employment, entitlement increases by 2 days
What is the best way to implement this functionality? The first option is fairly simple to implement as I have track the start/end dates of each leave year and the increment for each employee can be stored as an integer.
I guess I'm looking for best practice solutions to store the chosen method; how to store the relevant options and all in an extensible format allowing me to add further methods later.
I'm working with Ruby on Rails but the question is probably relevant to other languages.
Thanks
Robin
What about: Store the balance in Employee. Employee belongs to Company. When the time comes, set the balance by using something like
self.company.set_balance(self.balance)
So your employee assessor runs over all the employees and asks the company to recalculate its balance.
If it's a global policy, then you don't need to tell Company who the employee is, but if you needed to have special cases, you could pass the Employee to the set_balance method so that it would have more information about the employee being recalculated.
As for the Compay's strategy in how to increase the days, I'd put it in a model to limit the code changes needed if the strategy is changed.
If it's a simple rule, maybe just keep it in a key/value pair:
"holiday_entitlement"/"flat"
or
"holiday_entitlement"/"length of service"
I would not keep the the values (1 or 2) in the DB in order to avoid smart employees hacking into the DB and putting 'favourable' values in there :)
I want to make a to-many relationship that can save an instance of an entity more than ones.
for exemple, lets say I have two entities: buyer, product.
now I have a buyer "jon", and a product "tomato", jon should be able to have more then 1 tomato.
another solution may be to save a counter somewhere, but i cant find an efficient way to do so.
Two ways to do that, depending on your needs:
Create a different object for each individual tomato, so that you're modeling every tomato anyone ever purchases. This probably isn't a great strategy for tomatoes, where you don't care much about the individual objects, but it could be a good plan for cars, where each vehicle is unique and should be tracked separately.
Create an entity that represents a purchase transaction. Jon isn't buying the same tomato several times, he's buying some tomato several times. The thing you want to track isn't the tomato but the purchase.