Announcement

Collapse
No announcement yet.

Database Size

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Database Size

    Is there any reference guide to how the database size is affected by the sections, products and attributes we add to the store?

    With quite a large store (10,000 products), I always have my eye on overall database size, and am aware of the maximum access size of 2GB.
    I also understand that number of orders stored is a factor too, and understand how database compaction works.

    What I am trying to work out, is how much data I can afford to cram into my store, before it goes pop.

    With the revamp I am working on, I would like to add a number of custom variables to my products, to enable more advanced searching (by author, genre, publisher etc).

    I would like to have an idea of how adding each additional variable will affect the size of my database.
    I realise this is a bit of a "how long is a piece of string" question, but is there some way of calculating this?

    For example, if I add a custom variable called "author" with an average field size of say 20 characters, to 10,000 products, what is the net effect on the size of the DB.
    If all products have the custom variable, but only half of then have an entry in the field (the other half still have the variable, but its left blank), how much space is then used?

    This is one for the database experts, so I probably should be posting this in a different forum (CD - please feel free to move it if appropriate), but lets see if anyone has some answers.

    I did try to work this out by adding products to a test site, and checking how the dbf size changed, but the results are inconsistent (eg adding 1 product can add X KB, but adding another identical product adds Y KB!).

    #2
    I think Actinic is okay for 20,000 products. what you do with these products is of course a factor in size. Like you say trying to ascertain by talking about it, would be piece of string time.

    In short, why guess at something when you can try it and see? whatever you do will be inconsistent but it will give you a far better ballpark figure than some pie in the sky guess. Do 100 products, divide the affect by 100 and use that as a basis.

    Make sure the database is compacted before and after the measurements are taken though.

    Comment


      #3
      Out of interest Martin what's the size of your compacted mdb with 10000 products?

      Comment


        #4
        Thanks Lee
        Duncan - ActinicCatalog.dbf is around 139,700KB, which now I stop and think, sounds a bit silly compared to the theoretical limits of Access, running at 2GB.
        If my puter knowledge is correct - 2GB = 2000MB, meaning my store could 'in theory' be 14 times larger than it currently is!!
        Do these figures and my 'logic' sound correct?
        If so, where does this oft banded about figure of 10,000-20,000 products being about as much as Actinic is comfortable with, come from?
        I have a feeling that whilst 'in theory' the db could be 2GB, in practice, the software wouldn't cope.
        It already struggles on a fairly powerful computer, if I let the processed orders tab build up too much (dosen't like it much over a years worth - about 7500 orders).

        Anyway, back to my original query - do any of you use multiple attributes (custom vars) across a large product database?

        Comment


          #5
          Originally posted by fleetwood
          Thanks Lee
          Duncan - ActinicCatalog.dbf is around 139,700KB, which now I stop and think, sounds a bit silly compared to the theoretical limits of Access, running at 2GB.
          If my puter knowledge is correct - 2GB = 2000MB, meaning my store could 'in theory' be 14 times larger than it currently is!!
          Do these figures and my 'logic' sound correct?
          If so, where does this oft banded about figure of 10,000-20,000 products being about as much as Actinic is comfortable with, come from?
          I have a feeling that whilst 'in theory' the db could be 2GB, in practice, the software wouldn't cope.
          It already struggles on a fairly powerful computer, if I let the processed orders tab build up too much (dosen't like it much over a years worth - about 7500 orders).

          Anyway, back to my original query - do any of you use multiple attributes (custom vars) across a large product database?
          To get a very close to correct calculation multiplying by 1,000 is fine, the actual figure is 1,024. Don't ask me why, i did read it once to find out and thought, "yep, don't worry about that, just accept it".

          1,024KB = 1MB

          1,024MB = 1GB

          Like you say, you are way under this threshold and could probably double your site and still be ok. I think the main problem is system performance as you say. Although it is stated as ok for 20,000 products, i certainly wouldn't like a site with that many, it would be one damn cumbersome lump and uploading would be "go away for the weekend" sort of thing.

          With order details, i would imagine that an archive can be created, so that only orders of 3 months or younger are kept within actinic and an alternative database for archiving could be created etc.

          Comment


            #6
            2gb would take an awful long time to upload pages the way actinic uploads to the web
            scary . . .

            Comment


              #7
              alternative database for archiving could be created
              thats one of the attractions of multi- site - I intend to archive the shop every 6-12 months as non trading 'order reference sites - although, if there is a better way, I'm happy to use it. Currently, I just archive snapshots, in case we ever need the old orders, and delete them from the live site.

              On the subject of DB size, do I take it that the consensus is that adding extra fields (by way of additional attributes) to my largish product range, shouldn't slow things down too much?
              In the end, I can only try it and see what happens...

              The main reason for wanting to do this, is to improve the rather poor search facilities. Adding product attributes should enable me to build a better defined product search engine over time (actually, the thought of updating 10,000 products with new attributes sends a shiver down my spine, but I'm not scheduling it for some time yet - just thinking ahead!!).

              Comment


                #8
                If i wanted to archive the ordersi would create my own access database and move order details into that as a standalone database. You obviously need access to do this, however with it you can create as many copy database as you want.

                I think the variable will be fine. Put it this way, i would rather add a variable to every existing product, than add 10,000 more products. With the new workaround on variable imports, it should be a reasonably quick process.

                Why don't you use the meta content for your internal search engine?

                Comment


                  #9
                  Originally posted by leehack
                  To get a very close to correct calculation multiplying by 1,000 is fine, the actual figure is 1,024. Don't ask me why, i did read it once to find out and thought, "yep, don't worry about that, just accept it".
                  Computers run on binary code.
                  1x2 =2
                  2x2 =4
                  4x2 =8
                  8x2 =16
                  16x2 =32
                  32x2 =64
                  64x2 =128
                  128x2 =256
                  256x2 =512
                  512x2 =1024
                  Brian
                  www.flowergallery.co.uk
                  Same day flower delivery to UK
                  Same day flower delivery to Republic of Ireland
                  International Flower Delivery

                  Located in Argyll, Scotland, UK

                  Comment

                  Working...
                  X