This would be ridiculous. Theoretically if you had 400 companies, then each product would be listed 400 times to the products table when it only really needs to be listed once. Your database is going to be bloated and huge.
Database HELPPPPPP
- Thread starter Dave33445
- Start date
This would be ridiculous. Theoretically if you had 400 companies, then each product would be listed 400 times to the products table when it only really needs to be listed once. Your database is going to be bloated and huge.
EXACTLY!!!!!!!!
That is why I suggested an XML feed per user. I don't know how else to do it.
The program right now is stand alone software so when it installs on your local machine and you change pricing it only effects your local copy. To take this web based I need to have pricing for every user.
To take it one layer further. The default values change every week but existing users pricing doesnt change. (New users get new pricing, old users update their own pricing) so I can't store only changed values but have to store all values of product price.
That is why I suggested an XML feed per user. I don't know how else to do it.
The program right now is stand alone software so when it installs on your local machine and you change pricing it only effects your local copy. To take this web based I need to have pricing for every user.
To take it one layer further. The default values change every week but existing users pricing doesnt change. (New users get new pricing, old users update their own pricing) so I can't store only changed values but have to store all values of product price.
I'm with LotsOfZeros here, you are missing the point. I've also told you how to add everything quickly. You don't have to add 8000 products more than once, you reference each product against a price and a client. This way you only have everything once and can reference it as many times as you want.
And to talk of your latest post that doesn't really change much, you can just add another table of default prices and reference that.
Maybe I am explaining wrong as I intended to do what you explained.
I should have been more specific in stating I need to insert 8000+ items into the product pricing table per user. not the actual product (the desc, upc, etc stays the same)
I still believe the issue stands, how do I do 8000+ inserts in a browser?
I should have been more specific in stating I need to insert 8000+ items into the product pricing table per user. not the actual product (the desc, upc, etc stays the same)
I still believe the issue stands, how do I do 8000+ inserts in a browser?
Start here:
Simply SQL - SitePoint Books
If that doesn't work, try these:
Guru.com ? Find Freelancers for Hire. Get Your Project Done.
Outsource to Freelancers, IT Companies, Programmers, Web Designers from India, Russia, USA, and more - oDesk
Elance | Hire experts to do your work: outsource to companies, consultants and freelance professionals.
Freelancer.com | Online Freelance Jobs | Employment | Design | Outsourcing | Programmers | Web Design | Freelancers
Look, you don't need to do it per user, if you think you do, then your structure is seriously flawed. The beauty of MySQL designs when done correctly is little needs repeating.
And the easiest way imo to insert 800 records is to copy and paste them into notepad, write an insert command and import it using phpmyadmin.
Maybe i'm not thinking outside the box enough, but given the requirements i described based on the stand alone equivelant of this app, how would you do it?
Again, using thins like phpmyadmin is NOT POSSIBLE since my client is not tech savvy and can barely use a computer, I need a point and click way to add a new customer to the software for him to use.
Again, using thins like phpmyadmin is NOT POSSIBLE since my client is not tech savvy and can barely use a computer, I need a point and click way to add a new customer to the software for him to use.
You mentioned they will be using a desktop application. What desktop application are they using?
Take it from someone who actually works for an ERP software firm that writes software for estimating in the manufacturing sector, you don't want to create a separate record for products when multiple companies will be referencing the same product.
Take it from someone who actually works for an ERP software firm that writes software for estimating in the manufacturing sector, you don't want to create a separate record for products when multiple companies will be referencing the same product.
Sorry, had to get that out of the way.
Let's try and break this down (table schemas bolded):
You have 0 - N customers so you have a table for that:
Customer, fields: CustomerId, CustomerName
You have 8000 products regardless of whether you have 0 customers or 1000 customers. This initial catalog has no customer association and is modeled as such:
CatalogProduct, fields: CatalogProductId, ProductName, DefaultPrice
you can now set and manage the default price for without affecting existing customer prices
When a customer joins you can use either an Insert trigger on the customer table or an insert/select as a second batch after the customer record insert that will add the default catalog at the default prices for the new customer. This junction table is modeled as such:
CustomerCatalog, fields: CustomerCatalogId, CustomerId (FK to customer table), CatalogProductId, CustomerPrice
the customer can now override your default price.
So if you have 8000, standard widgets as soon as the customer signs up they will immediately have those 8000 records associated with them, if they want to set their own price you can move data into the browser as necessary and update it (think editable paged lists.)
If the customer specific products need to exist in the CatalogProduct table then add an additional field to CatalogProduct called CustomerId, for your 8000 default products the CustomerId field will be null, and you can insert defaults by querying for those records with a null value, and new customers won't get other customer products inserted because the non null CustomerId value records will be filtered out.
What i'm saying is, you populate things that are static using phpmyadmin, then you create a gui for the client to add/edit how they want it.
Now, from what i understand thus far, you have products, you have clients, and you have pricing. You also want default pricing for products, so if they don't change the price themselves, then it defaults to a preset value yes?
I mean is that the main thing? I'm starting to think maybe you're holding too much back for us to be able to properly help with the structure, but at the same time, i think you need to properly visualise your tables and how they interact.
But how would i do it? I'd add all products to the DB and anything else that needs referencing, then i'd build an html/php gui and check i can add and edit every aspect of the database from an admin side and a client side.
Now, from what i understand thus far, you have products, you have clients, and you have pricing. You also want default pricing for products, so if they don't change the price themselves, then it defaults to a preset value yes?
I mean is that the main thing? I'm starting to think maybe you're holding too much back for us to be able to properly help with the structure, but at the same time, i think you need to properly visualise your tables and how they interact.
But how would i do it? I'd add all products to the DB and anything else that needs referencing, then i'd build an html/php gui and check i can add and edit every aspect of the database from an admin side and a client side.