I am trying to design a database for my web app. The idea is that customers can come on and sell cars that are already listed in the database. Then there will be a list of offers made by other users on the cars.
Just looking for some advice really, not sure if my db design would work correctly?
also, for sale history, would i be better adding anouther table? or making a query to find sales with an offer with status (sold)?
Thanks
I have already written on comments but let me put them all together.
1) If you need some kind of history you would really want to throw some "created_at" datetime's on both carsforsale and offers.
2) putting a status on carsforsale would save you a lot of trouble when querying.
3) I see a balance in users table, would it change when user makes an offer? If not you would better invalidate the status of every offer when a car is sold (would be simpler with #2)
Offers table probably needs to have a userid to show who made the offer.
Related
Okay, my partners and myself created these a while ago. We are going to be transferring this into SQL through Visual Basic soon, but I want to make sure everything is ready to go. Two major complaints that we were not able to fix was...
"By having Transaction and Product directly connected you are unable to allow multiple products on the same order (customer can't order both a latte and cappuccino on the same order)."
"Membership table: Not sure what the data in DiscountTypeTotal means - do you have multiple pieces of data in the same field? (then your table isn't on 1NF).
It looks like you need to allow each member to have multiple discounts - so you need another table to capture that."
How do we effectively correct these? How else would we connect Transaction with Products? I understand that the customer can only purchase one item per transactions, so would we have products and another table for multiple items? Allowing multiple customers to have discounts, I am lost. Any help would be appreciated.
In mysql a User and Friend Table will somewhat look like these
User Table
id
name
phone
status [enabled/disabled]
===============================================
Friend Table
user_id
another_user_id
status [if friend or not]
===============================================
but in DynamoDb
I have been troubled about these two ways either
Approach 1.
User Table
id
name
phone
friends -> attributes
OR
Approach 2.
User Table
id
name
phone
===============================================
Friend Table
user_id
another_userid
===============================================
Im currently using the Approach 2. question is whats the best way to model tables in cost effective manner , latency and performance?.
PS: I emailed their support about these problems for me but still has no reply from them
so someone should already had gone through these problems.
I hope I iterated the question carefully to be understandable.
EDITED:
#chen
Q: Do you often query a user's friend list?
A: yes I will query every users-friends-list that will use my software
when a user logs in.
Q: Do you wish to know fast how many friends does a user have?
A: No, no need as long as i can get who the users friends are then its all good.
Q: How many friends do you think a user will have?
A: unlimited.
Q: How many users will the system have?
A: unlimited too.
thanks for giving the time.
thanks
David, you are running into a typical NoSQL problem.
When designing a relational database, you model the data as it fits the world, and also try to break the data into tables.
In DynamoDB (and other NoSQL) the real model is derived from the questions needing answers.
Do you often query a user's friend list?
Do you wish to know fast how many friends does a user have?
How many friends do you think a user will have?
How many users will the system have?
These questions will help you decide between approach #1 and #2.
If you comment with answers to these questions, I will be able to give you my thoughts on the model.
Regardless, if you really want to drop SQL, you might want to look at graph databases.
If you must use DynamoDB, then just keep references in the same table (approach 1). Have you already taken a decision on which DB to use? Couple of Reasons:
Some other NoSQL DBs have a vibrant community and great documentation.
GraphDB best seems to suit your problem above, but you are better aware of your systems' big picture.
I use access to store concert registration information at the non-profit I currently work at. I have it set up so that I dump all of the patron contact information into one table, and all of the concert registration information into another. when we change our concert season, I simply copy/paste the "2012-13 concert registration table" and rename it the "2013-14" concert registration table".
the concert registration table serves as my "hub" for all my other information. I have about a half-dozen summary queries that show information for specific concerts, who I still need to collect payment for etc. as well as many Word mail merges associated with each document. This setup works great, except that every season I need to go in and re-link all of the queries and word docs to the new registration table
I will be leaving my job at the end of next month, and I would like to make the database more user-friendly, especially since I am fairly certain that my replacement will have zero familiarity with access. my questions are:
1) Is there a more elegant, easy way to transition from season to season other than to create a new registration table and subsequent queries from year-to-year?
2) How can I idiot-proof this database for the new person when I'm gone? I'm scared that if I create an extensive "how-to" guide, it simply won't be read and the person will be forced to reinvent the wheel. I'm toying with creating a switchboard, but I'm scared that this will make the database seem more unapproachable.
Thank you for your insight, happy to clarify if there are any questions!
Just make 1 table. Call it "registration table" and add a new field called Season. Your queries will be include a filter for that field. Then you won't need to relink your queries, copy tables, etc.
For an example, say you have a query to pull all the information from that table for a particular season. It might look something like:
Select * from RegistrationTable where Season=[What Season];
When run, the query will prompt the user for the season and pull only that data.
Also, I do recommend the "how-to" guide. There's probably a lot of manual manipulation of the database that you do and don't even think about. And if nothing else, you can always say you gave them documentation and thus provided for your successor.
I want to create one database which can handle daily deals provided by partners.Also i want to design it in such way so that database it self will not allow duplicate data by using combination of lat-long, name & date-time. As for now i have one provider but in future i might get deals from 2-3 different partners.
Is one table is enough for above requirement which will handle all the data.
I will really apreciate any comments/ suggestions or hints to get me start or push in right direction. Any type of reference info.
Please let me know if need some more information or i am not clear about any point...
Regards,
K
I would at first put the partners in a separate table, to store all their information. Then, the deals only need a partnerid. It is unclear to me what these deals are, and if you may need a separate table with product information, so a deal is actually a link between a product and a provider, for a given period of time.
In that case, you need three tables at least to store just the deals, apart from any orders and other information you might need.
But if you start modeling, it is strongly advised that you do some reading about database normalization. It will give you a guide to what you should store in which table.
http://databases.about.com/od/specificproducts/a/normalization.htm
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)