As I have looked all over for an answer to my question and found nothing of use, I can only assume a) I can't use Google b) I'm the only one stupid enough to not know the answer off my own back.... So would be greatful for any advice or support on this.
Basically I'm setting up a basic e-commerce site. I have the standard products, customers, orders, orderdetails, addresses, and cart tables in place.
What I'm struggling to envisage is how to incorporate cataloguing into my design. There will be hundreds of products and downs of account but not all the products will be available to each account/customer. One customer may only have 4 products in their catalogue to choose from but another may have 50. Would merely creating a seperate catalogue for each customer (CatalogueID against Account ID), at the risk of repeating data, be my only answer?
Hope this makes sense.
Cheers.
I am trying to create a database for an online instrumental shop. I designed this database and added a cart table but I don't know if this is a good implementation for a online shop with cart.
The database sounds ohk and can be improved in many ways to make it even perfect one.
The following links gives u more detail in depth
https://www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html
Hi there working with bigcommerce Im looking to get the following style of break down on each category page
Essentially making a category version of;
%%Panel.HomeFeaturedProducts%%
%%Panel.SideTopSellers%%
%%Panel.HomeNewProducts%%
Ive gone ahead and attempted this however they seem to be pulling in from global values, and there dose not seem to me much option to break these down or limit the category, has anyone done this previously and if so how?
developerscott is correct in those panels not offering contextually unique data. I'd recommend looking into Unbxd. It has a 30 day trial so you can either investigate their programmatic solution or use it in place of making your own.
I am writing a small web site for work where employees can consult video capsules on how to use the different programs that we use. I was asked to organize the videos by categories and the categories need to be arbitrarily nested.
I've been looking into two ways to model this: nested sets and adjacency lists. They both seem to have their ups and downs, and I was wondering if somebody could help me choose the model that would best fit my usage scenario.
I want to display the categories in a menu along with the number of videos under that category
The site will be updated once a week, if that. The majority of the database activity is going to be reading.
The site will not be heavily visited. Never more than 2-3 users at once I'd expect.
Categories are likely going to be established when we build the site and rarely (if ever) touched afterwards. Maybe some categories will be added, but I don't expected categories to be deleted or moved around in the tree.
This is a summer job, so I expect that somebody else will maintain the site after I'm gone.
Thank you for you help.
If it's a small lightly used database that's unlikely to see a lot of change....I wouldn't sweat the issue. Don't spend a lot of time thinking on it: just do it in the simplest, most straightforward, easiest to understand/implement manner.
Git'er done, as they say.
category
--------
category_id
name
category_nesting
----------------
parent_category_id
child_category_id
video
-------
video_id
more_stuff
video_category
--------------
video_id
category_id
I am looking to design a database for a website where users will be able to gain points (reputation) for performing certain activities and am struggling with the database design.
I am planning to keep records of the things a user does so they may have 25 points for an item they have submitted, 1 point each for 30 comments they have made and another 10 bonus points for being awesome!
Clearly all the data will be there, but it seems like a lot or querying to get the total score for each user which I would like to display next to their username (in the form of a level). For example, a query to the submitted items table to get the scores for each item from that user, a query to the comments table etc. If all this needs to be done for every user mentioned on a page.... LOTS of queries!
I had considered keeping a score in the user table, which would seem a lot quicker to look up, but I've had it drummed into me that storing data that can be calculated from other data is BAD!
I've seen a lot of sites that do similar things (even stack overflow does similar) so I figure there must be a "best practice" to follow. Can anyone suggest what it may be?
Any suggestions or comments would be great. Thanks!
I think that this is definitely a great question. I've had to build systems that have similar behavior to this--especially when the table with the scores in it is accessed pretty often (like in your scenario). Here's my suggestion to you:
First, create some tables like the following (I'm using SQL Server best practices, but name them however you see fit):
UserAccount UserAchievement
-Guid (PK) -Guid (PK)
-FirstName -UserAccountGuid (FK)
-LastName -Name
-EmailAddress -Score
Once you've done this, go ahead and create a view that looks something like the following (no, I haven't verified this SQL, but it should be a good start):
SELECT [UserAccount].[FirstName] AS FirstName,
[UserAccount].[LastName] AS LastName,
SUM([UserAchievement].[Score]) AS TotalPoints
FROM [UserAccount]
INNER JOIN [UserAchievement]
ON [UserAccount].[Guid] = [UserAchievement].[UserAccountGuid]
GROUP BY [UserAccount].[FirstName],
[UserAccount].[LastName]
ORDER BY [UserAccount].[LastName] ASC
I know you've mentioned some concern about performance and a lot of queries, but if you build out a view like this, you won't ever need more than one. I recommend not making this a materialized view; instead, just index your tables so that the lookups that you need (essentially, UserAccountGuid) will enable fast summation across the table.
I will add one more point--if your UserAccount table gets huge, you may consider a slightly more intelligent query that would incorporate the names of the accounts you need to get roll-ups for. This will make it possible not to return huge data sets to your web site when you're only showing, you know, 3-10 users' information on the page. I'd have to think a bit more about how to do this elegantly, but I'd suggest staying away from "IN" statements since this will invoke a linear search of the table.
For very high read/write ratios, denormalizing is a very valid option. You can use an indexed view and the data will be kept in sync declaratively (so you never have to worry about there being bad score data). The downside is that it IS kept in sync.. so the updates to the store total are a synchronous aspect of committing the score action. This would normally be quite fast, but it is a design decision. If you denormalize yourself, you can choose if you want to have some kind of delayed update system.
Personally I would go with an indexed view for starting, and then later you can replace it fairly seamlessly with a concrete table if your needs dictate.
In the past we've always used some sort of nightly or perodic cron job to calculate the current score and save it in the database - sort of like a persistent view of the SUM on the activities table. Like most "best practices" they are simply guidelines and it's often better and more practical to deviate from a specific hard nosed practice on very specific areas.
Plus it's not really all that much of a deviation if you use the cron job as it's better viewed as a cache stored in the database.
If you have a separate scores table, you could update it each time an item is submitted or a comment is posted by a user. You could do this using a trigger or within the sites code.
The user scores would be updated continuously, and could be quickly queried for display.