pretty much noob here. What is the difference between these two schema for shopping website.
Normally I use this schema.
I saw this one here (https://github.com/ramortegui/e-commerce-db)
Should I keep using the first one or change to second. Is there any advantages?
In example 1 every product can have only one category.
Example 2 allows multiple categories per product.
To provide you better understanding,
Related
I am working on an app where users can create posts that uses Amazon DynamoDB. One of the attributes of a post item in the database is postId. I am searching for the best practice to set this value upon creation. So far, I have thought of:
Counting the current items in the DB and then assigning the value as postId = dbcount + 1. I cannot find a count method for DynamoDB using Swift, and the ways I have found (scan & description) are either inefficient or accurate. Also, I thought of the scenario of 2 users posting at the same time.
I could create a UUID with Swift and set the postId to this value.
Upon these 2 options, which route is better? Is there a preferred industry standard? Option 2 seems to be the better choice, but I am not sure. Are there any other potential alternatives? Thank you!
I would definitely stay away from option 1 - as you said the potential for a race condition is too high and it could be expensive to implement too.
A UUID would certain work and is likely to be the least painful. However, there are other options too. An atomic counter would work. A bit more complicated but you could even use a conditional write. But the logic for that would be a pain.
The advantage of the UUID is that you generate it so that it can be used for, as an example, a row of data in a child table.
I am currently working within Access 2013. I have a simple task that has been really driving me crazy these past few days, as I thought my relationships where correct. But when adding more data into the database I saw that there was a major problem.
Within the database everything is working fine between tblPersonal Information and tblPosition Applied for. The problem that I am running into is trying to successfully create the one to many relationship between tblPosition Applied for and tblOffer
I am trying to make it so that:
one person can apply to many positions (one to many)
one position that each person applies for can have one contingent offer (one to many) "the root of the problem that I am having"
Is their a field that I need to add, or create another table holding just the Personal ID to link tblPosition Applied for and tblOffer? I am really lost on this any help would be greatly appreciated.
If a Position_applied_For can have one-to-many offers, then you need to create a related field in tbl_Offer, just as you did for the one-to-many relationship between tbl_Personal_Information and tblPosition_Applied_For. Change tbl_Offer.Personal_ID to tbl_Offer.Position_Applied_For and relate it back to tblPosition_Applied_For.ID.
Right now there are no fields that are related except Personal_ID in the offers and applied tables. Essentially, there would be no way to distinguish if Person A applied for Job 1 and Job 2, and received an offer for Job 2.
In your tbl_Offer, there should be a Position_ID that relates to the Position. Also, assuming that the offer is only valid for one person, there is no need for tbl_Offer to contain a Personal_ID field, as it would be related through the tblPosition_Applied_For.
Hi I'm new to mongoDB and Mongoid and am little bit confused on when to use embedded documents and how deep to embedd.
So a fictional example:
Library collection has_many :books, which embeds_many :pages, which embeds_many :sections
Since I cannot work with say a Section directly I have to go trough books.pages.sections, right?
This would result in this route, libraries/:id/books/:id/pages/:id/sections/:id
Which seems a little bit crazy, best practice would be to only nest one level deep, right?
One way would be to have the route pages/:id/sections/:id and then stick the bookid in the request?
Would it be harder to query on say, sections? For example if I need to find all the books where sections has tag x?
However if I don't embedd all the way I would have an extra query?
Can someone shed some light? Thanks.
First of I believe that no one can give you the right answer about how deeply you should embed documents. It is highly dependent on your concrete project requirements. In general you should answer some questions to choose appropriate schema design:
Will users concurrently update same object in collection? (or what would my boss say if clients lost their updates)
Do I need support atomic operations?
Do I need to independently show nested collections or are they queried with the parent?
Do I need to sort embedded objects?
Do I need to query on embedded objects?
If you will answer 1,2-true; 3 I need show them independently (different page); 4,5 - true then i am sure that embedding will be some kind of pain in your ass.
Extra queries should not be a problem I guess.
These day I work with a database that have this style of relationship then I've been very confused with it. This database is in a very large web app & have worked well for 10 years then I wonder whether this design is good in someway? or in which situations I should implement it?
Welcome any idea!
There is nothing wrong in my opinion. You can have, for example, in a personal_data table a place_of_birth field and a place_of_living field both referring to a cities table. By the way you should post a more meaningful example to have a more precise answer.
Is it possible to create compound-Primary-key in Models in lift ? If yes, how ?
No, it's not possible in lift according to this mailing list,
where David Pollak say's
It's pretty non-trivial. I made some huge mistakes with Mapper and
making it super-not-easy to do compound PKs was one of a long list of
blunders. Sorry... but if I had a time machine, I'd got back 3 1/2
years and leave a note for myself that includes "Support compound
primary keys in Mapper.