Honestly I am very disappointed with all the seeming Experts dishing out information..and still no Shopping cart plug in for DBMAN..I use DBMAN SQL......I present have to do with ORDERNARY shoppinbg MOD..nice stop-gap but not the real thing...Alex pleeease do something about this....the internet is also for E-Commerce..isnt it?
Sep 7, 2001, 3:37 PM
Novice (27 posts)
Sep 7, 2001, 3:37 PM
Post #3 of 6
Views: 3939
Hello beck,
Thanks for you reply, Let me explain our business.
Here in Jamaica my company Jamaicasearch Limited operates a Local Webased Online Shopping Network.
NOTE: the network is local and not accessible from the internet except through long distance dial up
We use DBMAN SQL. with /MYSQL/ACTIVESTATE PERL/DBD/DBI to operate the database.
We use 36 different databases to cover different product categories (example) computer & Electroniic, Clothing, Furniture and Equipment, etc. what we would love to do is have "ONE" shopping cart (if that is possible) to serve all 36 different..what we have really is a LARGE SHOPPING MALL with 36 different shops. if its not possible for one cart to serve all, then I would settle with having the cart serve only one database. all we would do is install 36 copies of the shopping cart sotware.
from a discussion on the FORUM the owner koshervitamins.com uses CARTIT at cartit.com as their shopping cart and am obsolutely impressed with it. If we could get CARTIT to plug-in to DBMAM SQL them we would happy...as a matter of fact if you can do this we would be more than willing to pay for the information.
right now we are using 36 copies of ORDERNERY SHOPPING MOD as a temporary shopping cart. it woofully difficient.
You see as far as I am aware none has sucessfulyy integrated a sensible shopping cart with BMAM SQL..am i wrong???. PLease please please help us.
[Everton Johnson]
Jamaicasearch Limited
Kingston Jamaica
West Indies
Thanks for you reply, Let me explain our business.
Here in Jamaica my company Jamaicasearch Limited operates a Local Webased Online Shopping Network.
NOTE: the network is local and not accessible from the internet except through long distance dial up
We use DBMAN SQL. with /MYSQL/ACTIVESTATE PERL/DBD/DBI to operate the database.
We use 36 different databases to cover different product categories (example) computer & Electroniic, Clothing, Furniture and Equipment, etc. what we would love to do is have "ONE" shopping cart (if that is possible) to serve all 36 different..what we have really is a LARGE SHOPPING MALL with 36 different shops. if its not possible for one cart to serve all, then I would settle with having the cart serve only one database. all we would do is install 36 copies of the shopping cart sotware.
from a discussion on the FORUM the owner koshervitamins.com uses CARTIT at cartit.com as their shopping cart and am obsolutely impressed with it. If we could get CARTIT to plug-in to DBMAM SQL them we would happy...as a matter of fact if you can do this we would be more than willing to pay for the information.
right now we are using 36 copies of ORDERNERY SHOPPING MOD as a temporary shopping cart. it woofully difficient.
You see as far as I am aware none has sucessfulyy integrated a sensible shopping cart with BMAM SQL..am i wrong???. PLease please please help us.
[Everton Johnson]
Jamaicasearch Limited
Kingston Jamaica
West Indies
Sep 7, 2001, 7:35 PM
Veteran (17240 posts)
Sep 7, 2001, 7:35 PM
Post #4 of 6
Views: 3914
Sounds like a major flaw to have 36 different databases...you should learn more about Relational databases to reduce the number of separate databases.
========================================
Buh Bye!
Cheers,
Me
========================================
Buh Bye!
Cheers,
Me
Last edited by:
AnthroRules: Sep 7, 2001, 7:36 PM
Sep 8, 2001, 7:24 AM
Novice (27 posts)
Sep 8, 2001, 7:24 AM
Post #5 of 6
Views: 3897
Is relational database (MOD) applicable in DBMAN SQL?
Please I beg give me the best senario to as to how to manage these 36 product categories.
You see the the drill down search fields are different for a number of the categories and so I would like to maintain seperate search panels for the different categories...
never mind what i want though..please just give me you take of how best to do this.
anxiouly awainting your reply!!
Please I beg give me the best senario to as to how to manage these 36 product categories.
You see the the drill down search fields are different for a number of the categories and so I would like to maintain seperate search panels for the different categories...
never mind what i want though..please just give me you take of how best to do this.
anxiouly awainting your reply!!
Sep 8, 2001, 7:54 AM
Veteran (17240 posts)
Sep 8, 2001, 7:54 AM
Post #6 of 6
Views: 3908
Well, there are many variables that affect database structure design...But off the top of my head, here is what you could do:
PRODUCT TABLE
ProductID (AUTO, PRIMARY)
ProductName (TEXT, Not Null, DEFAULT = Null)
ProductDescription (TEXT, Not Null, DEFAULT = Null)
ProductPrice (DECIMAL, Not Null, DEFAULT = 0.00)
PRODUCT TYPE
TypeID (AUTO, PRIMARY)
TypeName (TEXT, Not Null, Default = Null)
PRODUCTTYPE
ProductID (Index, Duplicates)
TypeID (Index, Unique)
CUSTOMERS
CustomerID (Auto, Primary)
Name (TEXT, Not Null, Default = Null)
Address1 (TEXT, Not Null, Default = Null)
Address2 (TEXT, Not Null, Default = Null)
City (TEXT, Not Null, Default = Null)
State (ENUM, 'AL','AZ', Not Null, Default = Null)
Country (ENUM, 'Argentina','United States', Not Null, Default = Null)
PaymentType (ENUM, 'Credit Card','Check', Not Null, Default = Null)
ORDERS
CustomerID (Index, Duplicates)
ProductID (Index, Unique)
Quantity (SmallInt, Not Null, Default = 0)
DateOrdered (DATE, Not Null, Default = 0000-00-00)
Now, this structure allows you to manage fewer tables, the main trade-off is that you will have to do some coding to get values, like the ORDER AMOUNT, which would be a matter of multiplying the ProductPrice and Quantity columns.
What this allows you to do is track the number of products ordered by each customer. Basically, when a customer orders a "product", the Quantity field will be updated rather than adding a duplicate record.
But this is a more manageable structure, IMO.
========================================
Buh Bye!
Cheers,
Me
PRODUCT TABLE
ProductID (AUTO, PRIMARY)
ProductName (TEXT, Not Null, DEFAULT = Null)
ProductDescription (TEXT, Not Null, DEFAULT = Null)
ProductPrice (DECIMAL, Not Null, DEFAULT = 0.00)
PRODUCT TYPE
TypeID (AUTO, PRIMARY)
TypeName (TEXT, Not Null, Default = Null)
PRODUCTTYPE
ProductID (Index, Duplicates)
TypeID (Index, Unique)
CUSTOMERS
CustomerID (Auto, Primary)
Name (TEXT, Not Null, Default = Null)
Address1 (TEXT, Not Null, Default = Null)
Address2 (TEXT, Not Null, Default = Null)
City (TEXT, Not Null, Default = Null)
State (ENUM, 'AL','AZ', Not Null, Default = Null)
Country (ENUM, 'Argentina','United States', Not Null, Default = Null)
PaymentType (ENUM, 'Credit Card','Check', Not Null, Default = Null)
ORDERS
CustomerID (Index, Duplicates)
ProductID (Index, Unique)
Quantity (SmallInt, Not Null, Default = 0)
DateOrdered (DATE, Not Null, Default = 0000-00-00)
Now, this structure allows you to manage fewer tables, the main trade-off is that you will have to do some coding to get values, like the ORDER AMOUNT, which would be a matter of multiplying the ProductPrice and Quantity columns.
What this allows you to do is track the number of products ordered by each customer. Basically, when a customer orders a "product", the Quantity field will be updated rather than adding a duplicate record.
But this is a more manageable structure, IMO.
========================================
Buh Bye!
Cheers,
Me