I have a Printer Inventory system. I have Make, Model, Inventory tables and set relations between them.
Make holds Printer's Manufacture name such as HP, Dell, etc.. it has ID field as primary key autonumbering and Model has ID, Model, MakeID fields which MakeID is the ID from Make table.
In one form I have two Combo Box cbMake and cbModel I was able to set so when I choose Dell on cbMake the cbModel data is the Dell printer's model and if I change the cbMake to HP the cbModel is HP.
Problem that I have is when I save the data on my Inventory Table instead of saving Printer Make and Model it saves the ID number of the Printer Make and Model like I choose Dell which ID is one then Model XYZ which ID is 22 then 1 and 22 is being saved in my Inventory table.
How can I change this to save Dell and XYZ instead of the numbers?
Related
I have a table in which a certain column's data is sometimes missing, in which cases has just a dash.
But since there's another column which is unique, the missing data can be deduced from other rows.
In other words, I have something like this:
Unique model
Maker
Profit
abcd1234
-
56
zgh675
Company Y
40
abcd1234
Company X
3
zgh675
-
10
abcd1234
Company X
1
Which query can I use to automatically reach the following (the list of Makers is dynamic but every model can only go to one of them):
Unique model
Maker
Profit
abcd1234
Company X
60
zgh675
Company Y
50
?
You may aggregate by unique model and then take the MAX value of the maker, along with the sum of the profit:
SELECT model, MAX(maker) AS maker, SUM(profit) AS profit
FROM yourTable
GROUP BY model;
This approach should work assuming that each model only has one unique non NULL value.
In hotel booking websites, hotelier creates rate plans for each room category (Super Delux, Suit Room, etc.). And each rate plan has rates based on many things.
e.g. followings are considered as rate plans
Super Delux room (Room only) (Payment mode: pay#hotel)
Super Delux room (Room only) (Payment mode: pay now)
Super Delux room (Room + breakfast) (Payment mode: pay#hotel)
Super Delux room (Room + breakfast)(Payment mode: pay now)...
Followings are the things on which a rate plan varies
1: Date - Rates can be different for every day
2: Contract Type - Rates on application booking,website booking and travel agents are different
3: Occupancy Type - Rate for single person, 2 people and 3 people are different
4: rate_plan_rate_master is used to save these rates. We need to keep 2 years of data in this table.
.
.
.
50,000 Hotels * 40 Rate Plans * 6 Occupancy Types * 4 contract types * 730 Days = 8,760,000,000 records
Followings are the different approaches that I could think of
APPROACH 1
35,040,000,000 Records
.
.
.
rate_plan_rate_master table
date (pk)
id_rate_plan (pk/fk)
contract_type (pk/fk)
id_occupancy_type (pk/fk)
rate
.
.
.
APPROACH 2 : Dont keep occupancies in different tables
5,840,000,000 Records
rate_plan_rate_master table
date (pk)
id_rate_plan (pk/fk)
contract_type (pk/fk)
rate_single
rate_double
rate_triple
rate_extra_child
rate_extra_adult
rate_extra_infant
.
.
.
APPROACH 3 : Create different tables to save rates for different contract types (split table into tables)
1,168,000,000 Records in each table
rate_plan_rate_master_web
rate_plan_rate_master_mobile
rate_plan_rate_master_b2b
rate_plan_rate_master_travel_agent
Following things will help you understand the requirements :
Occupancy types won't change in the near future. Maybe 1 or 2 types could be added as extra_child2, extra_adult2...
Usually not all the hoteliers enter the price for all types of occupancies... Small hotels don't add prices for Triple, Squad, extra_infant, extra_child.
Should I use a composite key? Or the primary key of one column and unique constraint on other fields.
This table's PK will be passed in booking_details table
This table requires only 2 years of data, but that doesn't mean we would remove it once it gets older. We want the data for analytic purposes. So right now what I can think of is that every day we will run a service or job in laravel that will remove 2 years old data from this table and add it somewhere else. If this is a solution please help me where should I send it, another table, CSV file or something else.
I am creating a database and I am unsure of the best way to design my tables. I have a table of real estate properties and I want to store information about those properties - e.g. bedrooms, bathrooms, size... I may have additional information I want to store in the future if it seems useful - e.g. last purchase price or date built, so I need to be flexible to make additions.
Is it better to create a separate table for each "characteristic" or to have one table of all the characteristics? It seems cleaner to separate the characteristics, but easier programming-wise to have one table.
CHARACTERISTIC TABLE
id property_id characteristic value
1 1 bedrooms 3
2 1 bathrooms 2
3 1 square feet 1000
4 2 bedrooms 2
...
OR
BEDROOM TABLE
id property_id bedrooms
1 1 3
2 2 2
...
BATHROOM TABLE
id property_id bathrooms
1 1 2
...
Forgive me if this is a stupid question, my knowledge of database design is pretty basic.
I would suggest a middle ground between your two suggestions. Off the cuff I would do
property table (UID address zip other unique identifying properties)
Rooms table ( UID, propertyID, room type , room size,floor, shape, color, finish, other roo specific details ect..)
Property details (uid, propertyID, lot size, school district, how cost, tax rate, other entire property details)
Finally a table or two for histories eg.
Property sales history(UID, PropertyID , salesdate, saleprice, sale reason, ect..)
Often grouping your data by just "does it match" logic can yield you good results.... care needs only be taken to account for 1to1 and 1tomany relationship needs of tables.
I am focused to this:
"I have a table of real estate properties"
Now as far as i knew you has to be a different type of:
Houses
Bedrooms
Comfort room and so on.
For further explanation:
You has to be a table of:
1. House type
2. House names,description,housetypeid,priceid,bedroomid,roofid,comfortroomid and any other that related to your house.
3. Bedroom type
4. Comfort room type
5. Dining type
6. roof type if it has.
7. House prices
8. Bathroom type
something like that.
One table with a few columns:
Columns for price, #br, #bath, FR, DR, sqft and a small number of other commonly checked attributes. Then one JSON column with all the other info (2 dishwashers, spa, ocean view, etc).
Use WHERE clause for the separate columns, then finish the filtering in you client code, which can more easily look into the JSON.
I have a problem of such:
Let's say I have an item, a CUP for example. I want to sell it, but want to allow the user to pick CUP properties, such as Size, Color, Material. When the user will select Size (maybe Large), color (maybe Black) and Material (maybe Glass) then I need to show him, that we have 20 such Cups in warehouse and the cost is $25 each. And now: I don't know how to store those combinations in database.
Here is my ultra stupid solution:
For each combination I will have a column, yet, adding any new combination might be painfull as well, as removing some, I will have to map them somehow, well...
Id | Product Name | LargeBlackGlassPrice | LargeBlackGlassCount | SmallBlackGlassPrice | SmallBlackGlassCount | Medium...
stupid idea, but as for now didn't hit anything better :/
Hope it's clear what I want to achieve.
Thank you
Consider the following ERD:
The system administrator maintains a list of product categories, these may include, for example, cups. The administrator also maintains a list of features. These could include size, colour, material, and anything else that they decide is potentially important for any type of product. The administrator can then create an intersection of categories and features to indicate which features matter for a particular product category.
This establishes the "rules" for a catalogue of products. Which types of products do you have and what is important to know about each of these types products.
Now, to store the products themselves, you have the SKU table. Each individual product, for example: Large Black Glass Cups is stored in this table. You can store the current price of this product here. You can also store the stock on hand here, although I've recommended elsewhere to never store stock quantity directly. Inventory management is not the basis of your question, however.
For any particular product (SKU) you then have a list of product features where the specific values of each specific product are stored. The features that matter are the ones defined by the product's category as listed in the CATEGORY_FEATURE table.
On your website, when a customer is searching for items in a PRODUCT_CATEGORY, (e.g. Cups) you show them the list of CATEGORY_FEATUREs that apply. For each feature, you can create a drop down list of possible values to choose from by using:
select distinct PF.value
from CATEGORY_FEATURE CF
inner join PRODUCT_FEATURE PF
on CF.product_category_id = PF.product_category_id
and CF.feature_id = PF.feature_id
where CF.product_category_id = CategoryOfInterest
and CF.feature_id = FeatureOfInterest
order by
PF.value
This design gives your administrator the ability to define new product categories and product features without having to make database schema or code changes.
Many people are likely to point out that this design uses the Entity-Attribute-Value (EAV) pattern, and they are equally likely to point out that EAV is EVIL. I agree in principle that EAV is to be avoided in almost all cases, but I have also asserted that in some cases, and in particular in the case of product catalogues, EAV is actually the preferred design.
Table1 => Cup Master
Fields => Cup Id | Product Name
Example =>
1001 | CUP A
1002 | CUP B
Table2 => Property Master
Fields => Property_Id | Properties
Example =>
1 | LargeBlackGlass
2 | SmallBlackGlass
3 | MediumBlackGlass
Table3 => Inventory Master
Fields => Cup Id | Property_Id | count | price_per_piece
Example =>
CUP A | 1 | 3 | 45/=
CUP A | 2 | 2 | 40/=
CUP A | 3 | 2 | 35/=
CUP A | 1 | 3 | 45/=
CUP A | 2 | 2 | 40/=
NOTE: A cup with a particular property might be available and with other property might not.
Let try to reason how to solve your task. I will describe general conception and split it in some steps:
Define types of products that you are going to sell: cup, plate, pan and so on. Create table products with fields: id, name, price.
Define colours of products: black, red, brown. Create table products_colours with fields: id, name, price.
Define sizes of products: small, medium, large. Create table products_sizes with fields: id, name, price.
In simple case all types of products will have the same price and will store in table products.
In simple case additional price for colours and sizes will be the same for all types of products and will be stored in tables products_colours and products_sizes.
Create table customers_products with fields: id, products_id, products_colours_id, products_sizes_id, quantity.
Write a query for join all table together to fetch all products with colours, sizes and all prices from db.
In the script iterates through all rows and calculate price for every product as a sum of product price, size price and colour price.
To sum up: this is very basic implementation that doesn't include things like brands, discounts and so on. However, it gives you understanding how to scale your system in case of adding additional attributes that affect the final price of products.
I am developing an evaluation system for different programs that needs a lot of flexibility. Each program will have different things to track, so I need to store what data points they want to track, and the corresponding data for the person being evaluated on the particular data point. I am guessing several tables are appropriate. Here is a general outline:
Table: accounts
- unique ID assigned to each account. We'll call this 'aid'
Table: users
- each user with unique ID.
Table: evaluation
- each program will enter in the metrics they want to track into this table (i.e attendance)
- column 'aid' will correspond to 'aid' in account table
Table: evaluation_data
- data (i.e attendance) entered into this database
- column 'aid' will correspond to 'aid' in account table
- column 'uid' will correspond to 'uid' in user table
The input form for evaluation_data will be generated from what's in the evaluation table.
This is the only logical way I can think of doing this. Some of these tables will be growing quite large over time. Is this the most optimal way of doing this?
I'm a little confused about how accounts, users and programs all relate to each other and whether or not account and program are the same thing and that you used the terms interchangeably. I'm going to use different terms which are just easier for me to understand.
Say you have a website that allows freelancers to keep track of different projects and they can create their own data to track. (Hope you see the similarity)
Tables...
freelancers
id title etc
projects
id freelancer_id title description etc
data_options
id freelancer_id title
You can even add other columns like data_type and give options like URL, email, text, date, etc which can be used for validation or to help format the input form.
example data:
1 5 Status
2 5 Budget
3 5 Customer
4 99 Job Type
5 99 Deadline
6 102 Price
7 102 Status
8 102 Due By
This display 3 different freelancers tracking data, freelancers with the id's 5, 99, and 102. Deadline and Due By are essentially the same but freelancers can call these whatever they want.
data_values
id project_id option_id option_value
a column freelancer_id as you would be able to to a join and get the freelancer_id from either the project_id or the option_id
example data:
1000 1 2 $250
1001 1 1 Completed
1002 1 3 Martha Hayes
This is only showing information freelancer with the id 5 has input because option_id's 1-3 belong to that user.