Hi, The problem of BLOB storage with MySQL is not the actual storage of the BLOB data, it is the getting BLOBs to and from the client. Traditionally MySQL treats the BLOB data as any other data and as a result there can be major memory usage and performance issues as the BLOB is passed back to the client app. This is why no matter how clever the storage engine is in how it stores the BLOB, the main problem remains.
That is why the BLOB streaming daemon was developed because it allows the actual BLOB data to be streamed to and from the database server outside of the normal MySQL client/server connection. So you can have the best of both worlds: - Similar to storing the BLOB in the file system: BLOB references are stored with the normal table data, not the actual BLOB data, so the tables do not get bloated, and because the BLOB data is accessed through the BLOB streaming daemon it has little impact on server performance and memory requirements are not dependent on BLOB size. - Similar to traditional storage of BLOBs in tables: the BLOB will automatically be delete when the row referencing it is deleted and the application designer doesn't need to implement their own file system based BLOB storage. So if you are looking at BLOB storage systems please have a look at http://www.blobstreaming.org or the launch pad project: https://launchpad.net/pbms (not pbxt as Paul mentioned.) Sorry if this is a bit of a plug for PBMS but the subject was BLOB storage and that is PBMS's sole purpose in life. Barry On 2/16/10 8:21 AM, "Martin Gainty" <mgai...@hotmail.com> wrote: > > i agree with jerry > > > > put date/timestamps on each record..(that way you know when the record was > created/modified) > > Martin Gainty > ______________________________________________ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger > sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung > oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich > dem Austausch von Informationen und entfaltet keine rechtliche > Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire informez > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est > interdite. Ce message sert à l'information seulement et n'aura pas n'importe > quel effet légalement obligatoire. Étant donné que les email peuvent > facilement être sujets à la manipulation, nous ne pouvons accepter aucune > responsabilité pour le contenu fourni. > > > > > >> From: jschwa...@the-infoshop.com >> To: vikkiatb...@yahoo.in; vegiv...@tuxera.be >> CC: mysql@lists.mysql.com >> Subject: RE: how things get messed up >> Date: Tue, 16 Feb 2010 11:02:22 -0500 >> >>> -----Original Message----- >>> From: Vikram A [mailto:vikkiatb...@yahoo.in] >>> Sent: Friday, February 12, 2010 4:13 AM >>> To: Johan De Meersman >>> Cc: MY SQL Mailing list >>> Subject: Re: how things get messed up >>> >>> Sir, >>> >>> Thanks for your suggestion, >>> I will go for blob storage, because our application will maintain the data >>> on >>> yearly basis[stupersonal2008, stupersonal2009 etc.]. So i feel we may not >>> face >>> such kind of performance issue in our application. >>> >> [JS] It sounds like you are planning to have one table per year. Regardless >> of >> where you put your blobs, I think that is a bad idea from a design >> standpoint. >> It will make it harder to find historical information. >> >> If your database is relatively small, then I'd just keep everything in one >> table. If it is big, then roll data that is five years old into an archive >> table. That will give you only two places, and an easy-to-follow rule to tell >> you where to look. >> >> Regards, >> >> Jerry Schwartz >> The Infoshop by Global Information Incorporated >> 195 Farmington Ave. >> Farmington, CT 06032 >> >> 860.674.8796 / FAX: 860.674.8341 >> >> www.the-infoshop.com >> >> >> >> >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe: http://lists.mysql.com/mysql?unsub=mgai...@hotmail.com >> > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/201469230/direct/01/ ------------------------------------------------------------------------- Barry Leslie SNAP Innovation Softwareentwicklung GmbH Senior Software Engineer Tel: (001) 250 595 4228 Fax: (001) 250 595 4233 Email: barry.les...@primebase.com Web: www.PrimeBase.com SNAP Innovation Softwareentwicklung GmbH, D-22765 Hamburg, Max-Brauer-Allee 50, Germany Amtsgericht Hamburg HRB 61066, Geschäftsführer: Ulrich Zimmer, Paul McCullagh ------------------------------------------------------------------------- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
