I have a typical e-commerce problem.
my database schema looks like this
|product|
---------
|id|
|description|
|product_entry|
|id|
|product_id|
|size_id|
|color_id|
|style|
------
|id|
|style|
|color|
-------
|id|
|name|
styles: animal_printed, common, focused
colors: blue, green, yellow
So, my doubt exists when creating a new product.
There are a kind of rules I should follow
animal_printed can only be blue
common can only be blue and yellow
focused can be blue, green or yellow.
Where should I store a that rules in order to fetch them when creating a new product?
Should I just replicate one of the other products?
What about when I have to create a new rule? Should I replicate that rule por all the product?
Related
I'm building products database where a product may have multiple variants such as Size, Color, Shape, etc. for a single product. Tricky part I have trouble with is structure of the database allowing me to link the dependencies e.g. "Red" "M" "T-shirt" or "Blue" "XS" "Trousers" which in this case are variants color and size together. I want those variants to be generic so, I'm avoiding sizes, shapes, colors tables etc. Some items may not even have any variant at all or have just one e.g. just the color.
Ideally the shape would look like so
products
id
name
1
T-shirt
2
Trousers
variants
id
name
1
Color
2
Size
variant_values
id
variant_id
name
1
1
Blue
2
1
Red
3
2
XS
4
2
S
5
2
M
product_variants
I probably don’t even need variant_id here if I provide variant_value_id which already has relationship with a specific variant.
id
product_id
variant_id
variant_value_id
1
1
1
1
The product_variants structure allows me to have "Blue T-shirt" record but how do I have those variant_value_ids work together so I could store a Blue M T-shirt or Red XS Trousers etc?
Here's my best attempt
I have inspired my model from those threads...
Modeling Product Variants
Schema design for products with multiple variants/attributes?
...but could not find an answer that would apply to my case where I could combine the variants together.
I'm designing a database for an online-store.
The store has different kinds of products (different categories: cosmetics, multivitamins, etc)
Each product has different options (color - package size - etc)
this options can effect on the price (like package size) and also each product with specific options varies in stock for example :
golden rose lipstick- color: red - price:50$ -stock: 50
golden rose lipstick- color: red - price:50$ -stock: 70
some kind of multivitamin - package size:60 tabs- price: 60$ -stock:5
same kind of multivitamin -package size :120 tabs- price:100$-stock:6
how should I design product table to store all options with stocks and price ?
I need a way which would be efficient for filtering products based on their options.
Well just store it like the actual physical products. So treat each size and color like an individual product, because that's what it is. You can also check out how Magento did it in their database. It's good to look at how the competitors do it :)
http://excellencemagentoblog.com/blog/2011/09/07/magento-eav-database-structure/
I am implementing a voting feature to allow users to vote for their favourite images. They are able to vote for only 3 images. Nothing more or less. Therefore, I am using checkboxes to do validation for it. I need to store these votes in my database.
Here is what i have so far :
|voteID | name| emailAddress| ICNo |imageID
(where imageID is a foreign key to the Images table)
I'm still learning about database systems and I feel like this isn't a good database design considering some of the fields like email address and IC Number have to be repeated.
For example,
|voteID | name| emailAddress | ICNo | imageID
1 BG email#example.com G822A28A 10
2 BG email#example.com G822A28A 11
3 BG email#example.com G822A28A 12
4 MO email2#example.com G111283Z 10
You have three "things" in your system - images, people, and votes.
An image can have multiple votes (from different people), and a person can have multiple votes (for different images).
One way to represent this in a diagram is as follows:
So you store information about a person in one place (the Person table), about Images in one place (the Images table), and Votes in one place. The "chicken feet" relationships between them show that one person can have many votes, and one image can have many votes. ("Many" meaning "more than one").
I have pretty basic question. I'm designing a database to keep track of the chess games being played among certain group of individuals. I am thinking of creating one player table which will hold the details of each individual player. The primary key would be player ID.
My question is about associating games with players.
My initial thought is to create a games table. Each record in it will be a game, it will have 2 columns for players(player ids) who played it and third column will be a winner( or draw ).
What is the best way to design it? Should third columns value be a player id or I can just specify 1 if player in first column has won the game otherwise 0. How do I handle draw case? Do I insert some keyword?
I'd also like to know if there is some completely other way of designing this database.
Sublime, there are several ways you could define the structure of this database. Which design you ultimately choose depends on the performance expectations and the ultimate maintenance requirements of your database. I would recommend reading up on normalization which will give you some insights into the pros and cons of designing your tables in various ways.
To answer your specific question, I would:
Make a games table that consisted of the fields:
Game ID (primary key)
Player 1 ID (Foreign key to your players table)
Player 2 ID (Foreign key to your players table)
Game result
Important points to note here:
I included a game id primary key to uniquely identify one game from another. Without this, you will not be able to differentiate multiple games played by the same players. You may or may not require this in your implementation.
Game result could contain different sets of values based on your method of extracting the data into some meaningful representation. For example, some possibilities are to:
Have game result equal player id or 0 or -1 to indicate a draw. Least preferred, in my opinion, since this results in a consistency problem in the data that the field represents.
Have game result equal a pre-defined list of possible values (1 = Player 1 won, 2 = Player 2 won, 3 = Draw, 4 = Still in progress, etc). The possible values could be it's own table. This approach requires more extensive query planning.
You could also structure your data to consist of:
A players table - Player information
A games table - Game information
A results table - Game results information
In this setup, your games table would include only game id and the players id's. The results table would include the game id and the result of the game using one of the above solutions for identifying the winner.
Here are my views:
I don't like the idea of having the two columns 'player 1' and 'player 2'. When trying to get a list of all games 'Jeff' has played, you will have to check both 'player 1' and 'player 2' columns for his Id.
You could fix the above point by implementing a 'GamePlay' type of table, which has separate rows for each player. This way each player has their own outcome and are are held in a single column for easy querying.
A separate table for for possible outcomes would be tidy.
I've drafted up an example below
GameResult - Reference table for game results
GameResultId | Desc
01 | Won
02 | Lost
03 | Drew
Game - This is the game table, lists games. Can have details of location, date, time ect.
GameId | StartTime | Location | Ect
01 | 13:00 | Park | ect..
GamePlay - Have a row for each member-game interaction.
GamePlayId | GameId | PlayerId | GameResultId
01 | 01 | 01 | 01
02 | 01 | 02 | 02
This way, you can query by your players a lot easier.
(Such as getting a list of all players who have won a match)
SELECT
p.PlayerName
FROM
Player p
INNER JOIN GapePlay gp
ON p.PlayerId = gp.PlayerId
WHERE gp.GameresultId = 1
You could still easy query by game too
SELECT
gp.GameId
, p.Name
, gr.Desc
FROM
GamePlay gp
INNER JOIN Player p
ON gp.PlayerId = p.PlayerId
INNER JOIN GameResult gr
ON gp.GameresultId = gr.GameResultId
WHERE
GamePlayId = 01
I need to scrape Form 10-K reports (i.e. annual reports of US companies) from SEC website for a project.
The trouble is, companies do not use the exact same format for filing this data. So for ex., real estate data for 2 different companies could be displayed as below
1st company
Property name State City Ownership Year Occupancy Total Area
------------- ----- ------ --------- ---- --------- ----------
ABC Mall TX Dallas Fee 2007 97% 1,347,377
XYZ Plaza CA Ontario Fee 2008 85% 2,252,117
2nd company
Property % Ownership %Occupany Rent Square Feet
--------------- ----------- --------- ----- -----------
New York City
ABC Plaza 100.0% 89.0% 38.07 2,249,000
123 Stores 100.0% 50.0% 18.00 1,547,000
Washington DC Office
12th street .......
2001, J Drive .......
etc.
Likewise, the data layout could be entirely different for other companies.
I would like to know if there are better ways to scrape this type of heterogenous data other than writing complex regex searches.
I have the liberty to use Java, Perl, Python or Groovy for this work.
I'd be inclined to keep a library of meta files that describe the layout for each page you want to scrape data from and use it when trying to get the data.
In that way you don't need complex reg-ex commands and if a site changes its design you simply change a single one of your files.
How you decide to create the meta file is up to you but things like pertinent class names or tags might be a good start.
then describe how to extract the data from that tag.
Unsure if there is a tool out there that does all that.
The other, nicer, way might be to contact the owners of these sites and see if they provide a feed in the form of a WebService or something that you can use to get the data. Saves a lot of heartache I should think.