Guys I am developing my project in Mysql Workbench and have a confusion about my project.
I have few questions:
How do we manage different types of payments?
I mean my DB has a payment table and my system has 3 modes for payment.
1]Credit Card(Will store the respective information)
2]DebitCard(Will store the respective information)
3]Cash on Delivery(the payment is done in cash and will be updated later)
I have uploaded a image here to tell you what I was thinking
Bill table-Consists of bill generation and stuff.
Payment table-As to when the payment is done (I have added a type id and fks from all table so that I can use a if/else clause on the select method.) is this good practive?
Home table- is the cash on delivery thong
Is there any better method to do this? Please help.
I have further modified the image and have chucked out the type condition and instead I am using the if(payment_type) clause to access the respective DB, I believe this should get the job done. Is there any fault in this? Please help
Indeed. There is. I would go with inheritance.
Here a simple diagram:
You need to include your attributes and notations (oneTOone, manyTOone,...). Do some research for inheritance.
Look here: http://de.scribd.com/doc/7122945/ER-Diagram
And there are more if you google or stackoverflowle.
Regards ;-)
Related
recently I've been introduced into the database world so I am initiating with MySQL, but the problem comes when I am requested to create a database for an art event where adults and children have different entrance costs but like I'm not working with other applications, I have to do everything with SQL instructions so as this language has not -if- instructions I would like you to guide me how to do to assign automatically the cost of an entrance when I register an adult or a child inside a column called "entrance cost"
I have thinking to create an entity called "rate" where I place the maximum age with lower cost (for children) and otherwise assign the cost for adults, but I don't know how to make to compare this data when I register an entrance and assign the cost to the user variable "entrance"
I'm really confused with this exercise so I hope you can get it and help me with that.
Thanks in advance.
I think you need to create one master table to configure rates. and eventually, when you add user entrance data, you can map this with rates from master table.
Let's say we have RateMaster Table(RateId, MinAge, MaxAge, Rate).
You add multiple rate records here with MinAge, MaxAge.
UserEntrance Data will have age mentioned for user and you can refer their rates from RateMaster table.
Let me know if this helped.
In a nutshell, you need to work with another language. You can't do a dinamic application using only SQL.
I'd recommend you to use Spring Boot (http://spring.io/projects/spring-boot) with Java or Kotlin. It's a very straightforward framework that will help you a lot, even if you're a starter.
I'm in the process of creating a website and would like some advise on my database schema as I don't have very much experience in that field.
Say I had a site where 2 products were for sale, product1 and product2.
When a user buys either product they get a user account with a key to access their account. A user can download their product from their account page. That user can then at a later date purchase the remaining product and the product gets added to their account allowing them to download both product1 and product2 using the key given to them when purchasing the first product.
Payment information (payment method, transaction id, timestamp, etc) will also be stored.
I currently have my schema planned as so:
I feel that the way I'm doing it is not optimal and there are better ways to organize it. Any advise?
Hope you can help and thanks in advance :)
It is a good idea to start off identifying the objects your schema will store. It looks like candidate components might be
user
(user data)
product
purchase
These entities will be the tables you start out with. Add relationships appropriately.
Identifying the entities in your schema will (hopefully) keep you from outwardly expanding tables. You don't want to have to revise your whole schema for example every time you add a product. Similarly, you would not want to add a new table each time.
Once you've identified these, start putting them in normal form. 3rd normal form is generally recommended. You will likely find, as you have indicated in your schema, there is much redundant data that would fall under the purchase entity that separating it out to another table makes for a more maintainable schema.
This will eliminate redundant data in your tables which might later fall out of synch and help to identify where some data is out of place.
Here is the situation I'm in:
I just implemented a DNN site. I already have a huge database table of users. Now when my users come in to register for my DNN site, they're required to put in a first name, last name and DOB. I will then use this information to match their records to the existing user table via a SQL query. The only problem is I can't find "DOB" field anywhere, in any table or for that matter most of the rest of the profile information. Is it even stored in the database? or am I just blind?
The best answer I could find was from a dnn forum which stated
"User profile information is stored in several tables in the database. The 'Users' table is the place to start for basic information. There are several tables that have "profile" in the name that also are important."
I've looked through almost every table in the database, but with no luck...
I'm using DNN 6.0 with SQL Server 2008
I've looked everywhere but can't find it. Any help or guidance from anyone would be much appreciated! Even a paid solution like a pre-built module would work.
Thanks
Look in the ProfilePropertyDefinition table for the PropertyDefinitionId of the dateOfBirth property. Then, with that id, and the id of the user, you can query the UserProfile table to retrieve the value.
There is more at this blog post
http://erikvanballegoij.com/Home/itemid/28/Selecting-profile-properties-the-easy-way
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
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.