From: Dimitris Servis
Date: March 21 2007 10:13pm
Subject: Re: dumping large binary file in database
List-Archive: http://lists.mysql.com/plusplus/6466
Message-Id: <65b8aaff0703211513p694f5319lbf33fd57b0e5b9cf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_131199_25432872.1174515208297"

------=_Part_131199_25432872.1174515208297
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Warren,

that's exactly the case... the moment you get 2 clients writing in the same
file at the same time, whatever you do, it eventually scales to using
something like mysql....

thanks a lot !!!!

dimitris

2007/3/21, Warren Young <mysqlpp@stripped>:
>
> Dimitris Servis wrote:
> > and as it turns out probably not a MySQL++ issue
>
> You'd have exactly the same problem using the C API.
>
> > best thing would be to store the whole table as a blob
>
> Oh, barf!  You're completely ceding the special benefits of a SQL
> database server if you do that.
>
> If you just need network access, put the current binary file on a file
> share somewhere.  If that won't work for you, write a dedicated row
> access server -- think of a very lightweight, flat-file database here.
> You can do it in a few hundred lines of C.  Either way, you get rid of
> the MySQL overhead, you can still access rows directly, and it's
> maximally fast.
>
> But, only do that if this is read-only.  Once you start writing to the
> file at the same time as other programs are reading, you'll just end up
> reinventing MySQL.  If you're in that situation, I'd just look at
> something more lightweight...Berkeley DB, or SQLite, for example.  Don't
> reinvent this wheel...this is a problem very nearly as old as computers
> themselves.
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:
> http://lists.mysql.com/plusplus?unsub=servisster@stripped
>
>

------=_Part_131199_25432872.1174515208297--