Hi,
Do anyone have similar tests with OpenBase?
What are the experiences?
/Micky Holdorf
On 13/12/2005, at 9.20, Georg Tuparev wrote:
Dave,
In the past we did extensive comparison of several databases for
two projects - one similar to Alex' and the other is an
astronomical database - a c
Dave,
In the past we did extensive comparison of several databases for two
projects - one similar to Alex' and the other is an astronomical
database - a combination of many and large images and really
astronomical amounts of coordinates and other catalogue data.
According to my notes, the
Georg,
When you say that MySQL does not scale, at what point did you see
performance start to degrade? Was the degradation a function of the
size of the images, size of the database, the number of images, or
number of transactions? I have seen some degradation because of the
application m
Alex,
Based on my experience in the exact same type of project, I would
strongly discourage you storing images in MySQL. If you decide to use
FrontBase though, it should work fine if you use separate schemas and
raw devices... or possibly without them too. MySQL just does not
scale...
m
Thank You all for parrtecipating in this discussions.
I think that discussion thread has been very helpful.
Best regards
Amedeo
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.ap
So... If images are being stored in the database as opposed to the
file system, what would be the celling for the image size?
I have always been a supporter of the large images being stored on a
file system and pointed to through DB. This discussion caught my
attention, however.
The reason is
Yes...forgot to mention that the images are blatted out hierarchically and not into a single folder, precisely because of this issue. Each leaf folder had around 30-50 images in it. And I can confirm from some recent non-WO experience that database performance can be dramatically improved by being
I can confirm Geoff's words in principle. But there is a caveat. If you put more than, say, 2k files in a folder, the file systems slows down. We have a framework that deals with this problem by spreading files in auto-generated folders. Also it is always a good idea to store images (or other BLOBS
This is exactly how I did the Fortnum & Mason site - they had an extensive product catalog whose images were stored in a database. when the catalog was ready to go live, the images were exported to the file system under the web server. The web app had a runtime switch (mode = deploy) for the 'produ
I've used a hybrid approach before. Images are stored in the
database, but "cached" and served from the filesystem. That way, if
you wipe out the filesystem or install on a new machine, the images
are written to the filesystem again and served from there.
On Dec 9, 2005, at 11:53 AM, [EMAI
Hello again; bad form replying to one's own post, but nevermind...
I'm just wondering how iTMS serves it's content – does anybody know
how that bulk storage/delivery mechanism works? It would be
interesting to hear how that was done. Also, with this arrangement
I've discussed below, I wou
Hello Amedo & Thomas;
I've developed some classes that can stream data out of a series of
ordered BLOB's. This is used for a couple things in a couple of my
projects and it can also be used for storage of images and the
subsequent outbound streaming of images from a WOA. You can find out
Amedeo,
We've developed an electronic logbook that stores everything (text,
images, attachments) in an Oracle database. It has been running
probably for about three years now and has been working very well, so
far.
Personally, I prefer the database approach. There are at least a few
a
13 matches
Mail list logo
