According to my design I have car models(BMW, toyota, ...) and car types(coupe, sedan, van, ...). So my CAR table has those two tables primary key and price information.
My problem is that I have one more car type named "customizable". that car type dont have an exact price because its open for bargain. I mean a coupe BMW's price is always same like sedan BMW but customizable BMW varies.
Current design doesnt meet that need. How can I solve this.
It sounds like you need to store the negotiated price against the Allocation - since that's the table that has the Car and Customer in it.
Or you could add another table which gets queries when the Type is 'custom'.
Related
Let's consider I have the following not normalized table
1) warehouse
id
item_id
residual
purchase cost
sale cost
Currency
I tried to normalize this and I obtained this tables:
1) warehouse table
id
product_id
residual
cost_id
2) costs table
id
purchase cost
sale cost
Currency
Does that comply with database normal forms?
Thanks much in advance!!!
This should be a comment, but it's too verbose.
There's not enough information to provide an answer - we have to infer structure from context - and the context is confusing. Your initial record looks like a description of a product to be bought and sold - but you've named it as warehouse - which is a place for storing products. I've no idea what you mean by residual. Do you have multiple purchase costs for a specific product? If so how are they differentiated. Similar for sale cost. If ther are multiple costs involved why is the selling price tied to the purchase cost?
I don't know what "residual" means in this context. But just ignoring that ...
I doubt that there's anything to be gained by breaking cost out into a separate table. Let's say we have two products, "toaster model 14" and "men's shirt style X7". Both have a cost of $12. So you create a cost record for $12, and point both records to this. Then you realize that you made a mistake and the toaster really cost $13. So you update the cost record. But that will then update the cost for the shirt also, which is almost surely wrong. Having a separate cost table would mean that you would always create a new cost record every time you created a stock record. Nothing is gained.
The fields you have listed look to me like they all belong in one table. You'd also need an item table that would have data like the description, maybe manufacturer, product specs, etc.
Your warehouse table appears to really be a stocked item table, as it lists items and not warehouses, but whatever. I suspect it also needs some sort of serial number, or how will you link a given physical item in the warehouse to the corresponding record?
If by "sale cost" you mean the price that you will charge to the customer when you sell it, I doubt this belongs in the warehouse table. When a customer buys a product, do you tell him, "I can sell you the one that's in bin 40 in the warehouse for $20 or the one that's in bin 42 for $22. Which do you want?" Probably not. I suspect you charge the same price regardless of which particular unit the customer gets. The fact that the price you have to pay to your supplier went up between when you bought the first one and when you bought the second one normally does not mean that you will charge your customer a different price. You may raise the price, but you will have one price regardless of which unit is sold. Therefore, the selling price goes in the item table, not the warehouse table. If "sale cost" is something else, maybe this whole paragraph is irrelevant.
Here I have a Movie entity with all the attributes I need. What I am having trouble understanding is what if the DVD store has more than one copy and more than one format of each movie. For example, each copy of these movies is identified with the combination of Movie_ID and item copy number. So what I mean is when a customer rents a Movie Item, he/she actually rents a copy of the Movie - called an item. Example: "Batman" is a Movie...but your DVD copy at home is an Item. So what gets me lost is a customer can rent copies of the same of different Movie Items according to his/her quota. Is this ok what I did ? If not, what is one of the ways to do it ?
Movie item represents the copy of the movie right? the actual disk itself?
Lets rename it for now so i can explain better of course you can rename it to your liking.
Lets call it ProductInformation for now.
so you have a productinformation which in this case is linked to a movie. the ProductInformation needs to have an extra value however it needs to know if its a DVD Blue-Ray or something else.
So we will create another entity called ProductType. this should contain an ID and a TypeName which will contain the values DVD, Blue-Ray or something else.
Create a One to Many relationship between ProductType and ProductInformation.
There, now we have a productInformation with a type and a movie linked to it!
Add CurrentPrice and IsRental columns to this entity remove the price and isrental property from the movie entity.
You should change the relationship between productInformation and Movie as so:
One movie can have many ProductInformation, one ProductInformation can have only one Movie.
Now lets make a Product Entity. The product Entity will represent the actual product (the physical DVD, Blue-Ray or something else).
It will have an ID, maybe a barcode if applicable since it is a store.
Lets create a relationship between the ProductInformation and Product, one product can have one productInformation, one productInformation can have many products.
Now Remove the relationships you've had between your user (rename user to customer) and movie. movie is not physical, the customer will not rent a movie, it will rent a product. movie is nothing more but information about the product.
Now we need to create an entity ProductCustomer or maybe name it Transaction.
This will take care of our many to many relationship between users and products.
Give it an Id, ProductId, CustomerId, Price (Hey we added that at our ProductInformation didnt we?!, Yes we did, but prices change. the transaction will be in the database forever. so for bookkeeping purposes we need to give it a Price aswell, so that we know how much a customer had paid at that time.) move the properties rentaldate and returndate from movie to this entity (productcustomer or transaction), and remove them at movie. aaaand you should have everything fixed, all your worries should be resolved.
Sorry i cant draw a diagram for you, only just got this laptop. :-)
Hope my explanation says as much as a diagram would.
Hop the draft model helps you:
Im developing a Car Classifieds but im not sure of how is the best way to design something, there are some features of cars like if it have 2,4 doors, if it is 4x4 or 4x2, engine 1.6, 2.0.
All this features are particular for a car but they have to be limited to what that mode have, so each time someone is posting a bike for example it would not show the option in a drop-down for 4x4, or engines than that model.
I don't want to make this generic, it would only work for cars, so thinking in how it would be best for generic classifieds its not necessarily.
What would be the best way to design this?
More Info:
My problem is how to design the relation between a Car Model and a actual car, for example the Year of a Model could go from 1990-2000, when someone is going add a Car of that model i only want them to be able to choose from the options that model have. How do i store this in a database?
You need to differentiate between a car model instance ("my car vin xxx") and a car model specification ("2009 Mazda 3"). In general a model spec has a model number and a model instance has a serial number (the VIN in this case).
You also need to differentiate between the available options for a model spec and the actual installed options for a model instance.
/* the model specifications: */
vehicle_model
id
model_name
from_year
to_year (nullable)
manufacturer_id
/* engine specifications */
engine
id
name (ex. "Cummings Turbo Diesel")
...
/* available engines for a model. you would use this table to show only the appropriate engines for a given model spec */
vehicle_model_engine
model_id
engine_id
/* vehicle instances: */
vehicle
id
vin
model_id FK vehicle_model
engine_id FK engine
You could either put a multi-column foreign key from vehicle(model_id, engine_id) to vehicle_model_engine(model_id, engine_id), or just put a single key to engine(id) and use application logic to check before saving.
I work at an automotive company, and I would recommend starting with year, make, model and trim. All cars have these values. You can hardcode those into a database structure.
Beyond that, just make an attribute table that will have those additional attributes.
Don't bother trying to make fields specifically for engine, number of doors, etc. You'd be surprised that some cars have more than one engine (!).
Tables for YMMT and attributes:
Vehicle
vehicle_id int not null (auto increment),
year int,
make varchar(100),
model varchar(100),
trim varchar(100)
Vehicle_Attribute
vehicle_id int,
attribute_name varchar(100),
attribute_value varchar(100)
I was a little miffed about the one-to-one relationship explanation on the 'I Think You Mean A Many To One' article.
In this instance for example, a product has one price because the business in question is small, niche, localized and supports only a single currency. Multiple prices per product make no sense in this case? I'm doubtful I'm grasping the concept correctly though, because everywhere I read says it will probably be a many-to-one even if you think it isn't?
Can somebody enlighten me please? :)
In an attempt to gain more reputation so that I can help in comments instead of an "answer" The one-to-many vs one-to-one is this
View a one-to-one as an extension of the table you are looking at.
Table B extends Table A. Meaning the information wasn't necessarily relevant enough to include in the table directly, but has a bidirectional relationship with each other. Basically meaning that As Table A, I am not dependent on the information in Table B, but Table B's information is very dependent on me. For the price example it means that Table A has a row related to a row in table B. So if you entering unique information in your Price table around every item to match in Table A, then this would be useful. As in say you had a description column about the item in your price table. Otherwise the price table in this case may just be irrelevant to have in the schema.
in a one-to-many relationship Table B usually has no reference back to Table A. So in the case of price, the items you are looking at do have a price, but prices aren't exclusive to items. So to better define, A number of things may have the price 9.99, but 9.99 only needs to exist in your pricing table once.
I am not familiar with the article you refer to. However, price is a classic example of a slowly changing dimension. Price may be constant at any point in time, but over time, the price changes.
Such dimensions are typically implemented by having effective and end dates for the period in question.
Now, at a given point in time, a product probably does have only one price. Things that affect the price -- coupons, discounts for the purchaser, volume discounts, for example -- are not properties of the product. These are properties of the transaction.
That said, there may be circumstances where a fixed volume discount does not make sense. So, the "price" for a product might include volume, as well as time.
In any case, I would agree with you that price is not a good example of a 1-1 relationship. There are other factors such as time and volume that affect it.
Say I have a product with attributes - id,name,UPC,price
You can see it as a database table 'product'.
Now I'm having issues wrapping my head around this problem.
Say this same product can be in the UK so the - name, UPC, price might be different.
It would make sense to do one product table for USA, and another for the UK but it sounds redundant. Is there a better solution?
You could do a price table where the key is product id and a location. You could add other dimensions in there as well. e.g. maybe some prices are sensitive to time of year?