I'm trying to learn DynamoDB and i can't lie, i'm struggling to figure out best practice to make the named in relationalDB world "many-to-many relationship" between 2 tables into a single table on dynamoDb.
A simple example: A table with Drivers (driverId, name, address, skill_level)
and a table with Cars (racing_id, brand, model ,color, last_service_date).
A driver can drive many cars and one car can have many drivers
Example use case: Get all cars for the specific driver(cars he drives)
I know it has to be done with a GSI index, but the best i can get is only the racing_ids from all the cars.
An adjacency list is the usual way this is addressed in DynamoDB. In this case you would store your driver and your car as items in the table and then you would also store a CarDriver that would hold the relationship between the car and the driver. You use the GSI to maintain the back links so you can see either side of the relationship. Typically some (duplicate) car and driver information may need to be stored in the relationship item so that It can be viewed in the opposite view.
The tricky part is learning where to put the data and where/when to duplicate the data. A lot of this is based off the access patterns.
In your example CarDriver would probably contain The Driver's name, and the car's brand, model, and color. Typically what I would do is make an attribute called car_embed that is a map with brand, model and color as key's in the map.
PK
SK
GSI1PK
GSI2PK
Entity_Type
Driver#1
Driver#1
Driver
Driver#1
Car#1
Car#1
Driver#1
CarDriver
Driver#2
Driver#2
Driver
Driver#2
Car#1
Car#1
Driver#2
CarDriver
Driver#2
Car#2
Car#2
Driver#2
CarDriver
Car#1
Car#1
Car#1
Car#1
Car
Car#2
Car#2
Car#2
Car#2
Car
If you want to really understand this you need to read the DynamoDB Book
Related
I am trying to design a product database using FileMaker 14. Our products are mainly:
Adapters: HDMI to DisplayPort; USB to VGA; USB to Ethernet; SD/micro SD card/Compact Flash readers etc...
Docking Stations: USB-C to DisplayPort/HDMI/USB-A 2.0/USB-A 3.0/USB-C 3.0/USB-C 2.0/AUX-in/AUX-out, etc...
USB Hubs: 2/4/6/8/10-port USB hubs, can be powered by bus or power adapter, with or without Ethernet, etc...
Possibly other types of product in the future
I want the database to be able to, among other things, output a spec sheet, which will include:
Model Number
Product Name
Image (one if printed, multiple if shown on laptop or tablet)
Upstream interface (All kinds of video, data, audio)
Downstream interfaces (All kinds of video, data, audio)
Power source (Bus or power adapter, different types of power adapters)
Dimensions
Weight
Operating environments
Supported operating systems
I've tried to normalize these as best as I can, but I'm confused with how the interfaces should be implemented. Options I think I have:
Lump them together in one table
ProductUpstreamInterfaces:
ProductID (primary foreign key)
USB-A2
USB-A3
USB-B
USB-C2
USB-C3
Thunderbolt1
Thunderbolt2
Thunderbolt3
AUX-in
AUX-out
HDMI
.
.
.
and
ProductDownstreamInterfaces:
ProductID (primary foreign key)
USB-A2
USB-A3
USB-B
USB-C2
USB-C3
Thunderbolt1
Thunderbolt2
Thunderbolt3
AUX-in
AUX-out
HDMI
.
.
.
Where the values for each field would be the quantities.
Break them apart
ProductInterfaces:
ProductID (primary foreign key)
InterfaceID (foreign key)
Quantity
Direction_1Up2Down (1 for up; 2 for down)
and
Interfaces:
InterfaceID (primary key)
Interface (eg. HDMI/DisplayPort/USB-C2/USB-C3/AUX-in/AUX-out, etc...)
Option 1 seems really messy.
Option 2 seems better, but I'm not sure if I'm going to run into any problems down the road... Which of the two is better? Is there a better way to do this?
With very few exceptions, anytime you have many of Y (interfaces) related to one X (product), you should put them in separate tables. When the join itself has attributes (such as Quantity in your example), there can be no exceptions.
OTOH, I don't see why you would need the third table ("Interfaces"). Does it have any other fields besides those shown? If not, a custom value list should be quite sufficient.
Caveat
Make sure you don't overthink this. Sometimes a list of interfaces is just text in a field. It all depends on what your solution intends to accomplish. A many-to-many relationship, supported by a join table, is useful when you need to track which interfaces are in use in which products, be able to quickly create/modify the interfaces for a product, perhaps produce some statistics (e.g. "80% of products in category X feature interface Y"), etc. Otherwise it's just waste of resources.
It is needed to store following information:
User device data like device id, device brand, screan size, type (pc, tablet, mobile).
Actual facts, like odrder id, total cost, goods count, goods ids etc.
How where to put user device data - fact or dimension table?
If I put it to fact table, I have a lot of duplicates, e.g. each row have to cotained detailed information about device, with is mostly the same for one user.
If I put it to dimesion table, I have to update dimension table - add new device or update older.
Important note here is analytical system designing not only analyze user behaviour, but to see where data is not gather. So there can be a situation when different application versions provide different "fullness" of information - 1st version gather 50% of user device, 2nd - 75%, 3rd - 99%. So I have to update (not only insert) data in devices table.
You need at least two dimensions i.e. User and Device with Snowflake Schema. The user dimension should reference the Device table with Device ID.
User will just keep a list of users. It will use foreign key to reference the Device table(on say Device ID). You might go for any SCD type to handle data changes. But it will definitely better in comparison to if all the device fields were on a single table.
Device table will hold the different types of Devices and their attributes.
The fact would then just need to reference (UserID, DeviceID) combination from User table.
I know this seems silly but I'm having a really hard time with this structure.
My data model is for a computer store (strictly academical only), so I have a generate product table for things like, title (i7 4790) description, unit price and specifications. Then it links to suppler and Category.
Category will have all the parent Category's like motherboard, CPU, power supply etc.
But now I'm not sure if I should then go and have a table for each of, referring to the category table, so motherboard would have things like, chip set and socket, CPU could have a chip set as well, and maybe clock speed, power supply could have capacity.
But then I could have a sub category table That referring to itself, but I'm not fully sure how to structure that.
Please could you help me with the right design decision and why it's the best decision, also what are the pros and cons per solution.
EDIT
Here is a quick Model that i wiped up of my thinking so far. The product table will hold the general details of all products, such as Name of the product, Unit price, Description and Specifications and they will then link to the catagory table that will then link to the different tables, like motherboard, CPU, Memory etc.
The reason im thinking like this is because each catagory, Motherboard, CPU Case etc, is an entity on its own, an object on its own, so it deserves a table of its specific attributes.
Am i on the right track ?
I just answered a question along these lines. You can have a Product table with all the data that is common to all products (SKU, shipping weight, mfg, mfg order num, retail price, etc.) and then, using the Categories value, place category-specific data in separate tables, using the category value to enforce the integrity of the whole system.
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'.
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)