Toggle sidebar

Databases on websites

Sort by date Sort by votes
W

welshman83

Free Member
Mar 10, 2011
21
1
This is one for the experts I think...

My question is when building a website with a MySQL back end and all the products running off a database, do developers use a single mass database of 1000's of products, or assemble many smaller databases that are uploaded in batches?
 
If you're working 1000's of products they are fine to go in one database, but what you should be doing is splitting the data into seperate fields.

Product name, status and other key info goes in one table and then description etc goes in another table. This allows you to quickly reference products without searching through huge amounts of data.
 
Upvote 0
I am a bit confused by the question really but:

You would use 1 database to hold all the records for 1 site, you'd have to be very odd to use multiple databases.

If you have more than 1 web site, it wold depend on the setup, but you wouldn't generally get the records for 1 site from 2 different databases that could be classed as bad design, becuase when you open connections to the database thats cause work and every time you do it it creates work, so to do it twice is daft unless there is a real need to.

below is the link to the magento database schema (no idea how upto date it is) but it should give an idea.

http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_database_diagram
 
Upvote 0
Thanks for that.

The reason why I ask is because my website is being built, and I just like to know what I am talking about.

For me it didn't make sense to constantly update a database, as you have to dump and re-upload everytime you update the database? But if that the way it is done then fair enough.

Also, a question regarding search variables on the left hand side. If you have grouped variables to search by e.g. £200-£250, if the price is say £225 then the database should automatically assign this variable....you shouldn't have to do it manually should you?
 
Upvote 0
When you search the database you can tell it to search higher than, lower than or equal to a price range. Databases are standard procedure really, it'd limitless what you can do with your data once you're pulling it from a database.
 
Upvote 0
A database is a complex bit of kit, its designed to be queried alot, good coders will build in good code and database design to get the most out of it.

Database and programs only do what they are told, you have to program them to get the results you require, if you want to search for specific amounts then you program that, if you want to to do a to and from range you need to program that, then how does the user put in the information, you also need to program that in a way the user will understand, putting £250-300 in a text box to get a price range isn't standard so is there a point in building it?

The idea is you keep the content in the database update, and then the code will do the rest. There are lots of ways to not call the database everytime you need some information but thats down to how good your coder is, you can call a database then store that in cache and then call the cache, but it all depends on the build becuase your using up memory storing it in he cache, so its a trade of one for the other, again its all down to the programmer and the project.

The other issue is there are no real right and wrong ways to do it, its alot down to personal choice, knowledge and end result.
 
Upvote 0
TotallySport said:
The other issue is there are no real right and wrong ways to do it, its alot down to personal choice, knowledge and end result.
Click to expand...

There is a wrong way to design a database and there is a right way. A database schema should be developed in such a way that no data is replicated.

With regards to the comment earlier that a full upload is required on the database, this is incorrect. You can update data in the middle of a database with ease. Your developer should do this within the code of your site.

Has your developer supplied you with a functional design specification? This basically outlines how the work is going to be done and the design behind it. If not, ask for it. The developer, if they're worth their salt would have the design written down before they even attempt any coding. This will prove valuable to yourself in the future if you no longer want to work with this developer in the future and you have to pay someone to read through all their code to understand what's going on.

If they have supplied something like this then feel free to send me a PM with the details and I'll happily review it FOC to make sure it's being done correctly. I've been doing this type of work for quite some time now, just not for websites......industrial software is my background with nuclear waste facilities and a website background for my personal life.
 
Last edited:
Upvote 0
peteoc said:
There is a wrong way to design a database and there is a right way. A database schema should be developed in such a way that no data is replicated.
Click to expand...
I disagree, there are good database design and bad, but as long as the end results does what its supposed to and the person is happy with it, there is no right or wrong.

You can always improve database design, or adopt different techniques to improve performance, worrying about those things at the start will delay everything.

I do agree that getting people in the know to do it, will vastly increase build time and quality.
 
Upvote 0
this is why you would use bespoke,


  • Existing open-source and commercial solutions. There are a range of popular open source (free) software and commercially available software for a nominal fee that will provide an 'out of the box' solution when you require an online shopping cart. The cost in implementation of these is in setup, configuration and customisation of the design of the site. While you get a lot of 'bang for the buck' these systems are designed to be generic to suit a multitude of product types and sales scenarios so the customer and administration experience can be more complicated than it needs to be. The layout and operational flow of such solutions can be limited in how far they can be customised beyond their existing features, although often they have a range of available modular addons that provide additional functionality.
  • Subscribed e-commerce services In this scenario you pay a monthly or annual fee to a provider that hosts your site. The features are as provided so no additional customisation can typically be added, although the design of the site can be tailored to your brand. These services typically impose a transaction fee where a small amount of each sale is retained by the service provider. This is usually proportional to the service level subscribed to, with higher monthly fees attracting lower fees per transaction. The initial investment required is low but ongoing costs are constant.
  • Bespoke and custom ecommerce development While the most expensive solution when it comes to initial investment, a bespoke solution means that any feature required can be implemented, and any design or layout can be created for the shop without compromise. The best customer shopping experience, product presentation and user interface can be tailored exactly for the product range while a more efficient administration backend can be created with respect to the operational scenario. The flexibility and enhanced user experience will usually pay benefits in the longer term and generate a better return on investment.
Its all about being able to do what you want when you want and the longevity of the product.

be-spoke is by far the best solution if you can afford it but off course it comes with a price tag.
 
Upvote 0
TotallySport said:
You can always improve database design, or adopt different techniques to improve performance, worrying about those things at the start will delay everything.
Click to expand...

In my experience database design is one of the highest things on the list of "things to get right from the start". Once you've got a database up and running it can be a nightmare to correct problems in design.
 
Upvote 0
FreshPage Web Design said:
In my experience database design is one of the highest things on the list of "things to get right from the start". Once you've got a database up and running it can be a nightmare to correct problems in design.
Click to expand...
You will never be able to predict everything your database will do down the line, sitting worrying about it IMO is a pointless task. So in effect you will nver be able to get the database right from the start, some issues will come up in developement, new technologies and systems will allow better and easier use. You will only have problems changing the database round if your coding is rubbish, but you don't get that knowledge without experience.

I have just read up on multi laungauge database design, combine with globalization and locaziation, there was a least 10 different ways to set it up, and that doesn't include the different coding structures, if you worry about it at the start you will never start building it.

I am not saying its not important, but as I said if it works no one is going to care, or know if its the sleakest designed database or not. Once its built and you see you can improve performce then your coding comes into place to how easy it is to change, again worrying about which programming model to worry about will also mean you will never start.

If you an experience Database admin, then if someone says they need x y and z it would be easy to say you willl need this and set it up like that, but if your a newbie then there is no way you will get it right first time, as long as it works you can always build on that.
 
Upvote 0
You must log in or register to reply here.

Latest Articles

Top Bottom
Back