Re: managing tablespaces like files?

Justin,

It is an image viewing system for events. Each event could have a few
hundred images (each one will be between a 3 to 12 megs file) and as many as
one hundred thousand images. So these are the other files, the other
folders is how all these images are stored and managed. The database
contains basic customer info and references to the images they picked (path
and image name). Each event is a unique entity, such that the customers and
their selection of images are unique to the event in which the images where
created. Because of this, right now I am using SQLite which creates a new
"event" database for each and every event. Depending on my customer, some
folks simply delete the whole event when it is over, while others back it up
off their dedicated event server machine and load it up on their desktop at
home to finish processing the images.

The images are served up via the Apache web server, so currently there is
only one process access the SQLite process, well, possibly two or three,
depending on how many instances Apache start, but it is limited and there
are a ton more reads then there are writes.

Why I am looking for other options is it time to develop some new .Net
client modules to access the data in new and different ways. Initially I
was going to have everything access the data through Apache, but now I am
thinking that I can speed up the time to market if I where to move to a
traditional database and let the new .Net clients connect directly to the
database.

From the prospective of my end users, most who know NOTHING about databases,
keeping a file based database makes a LOT of sense. From the standpoint of
eventually taking this to also be hosted online, it makes a LOT of sense to
rework the current model to one central DB that can hold multiple events.
The only question is how do I keep the system user friendly for my
customers that know nothing about computers. That is the question. In the
end, my software is all about letting my customers have their cake and eat
it too!

Sam

On Tue, Mar 9, 2010 at 2:15 PM, Justin Graf <justin(at)magwerks(dot)com> wrote:

> On 3/9/2010 12:45 PM, Sam Carleton wrote:
>
> On Tue, Mar 9, 2010 at 10:06 AM, Justin Graf <justin(at)magwerks(dot)com> wrote:
>
>>
>>
> Justin,
>
> Thank you for the reply. My application uses two databases at one time:
> system db and the "event" db. The system db is exactly that, used all the
> time, aka system settings. Each time a user starts the program, the user
> has the option of creating a new event. The concept is that an event is
> like a MS Word Document, so every time a user creates a new event, a new db
> is created along with a number of other files and folders.
>
> It is very natural for my customers what to pick up the event and copy
> it/back it up to another drive and/or computer. What I am doing now is
> running throw the pro's and con's of changing the model such that all the
> different events are stored in one database. There
> are differently advantages, but there are also drawbacks. Life as a one man
> MicroISV, what fun! ;)
>
> Sam Carleton
> http://www.PhotoParata.com
>
> For more comments you will have to explain what the other files and folders
> are doing.
>
> If the database stays small and does not need to manage simultaneous access
> by different users then Postgresql, MSSQL, Firebird, Mysql will just cause
> more headaches than what you gain.
>
> If the files are shared and accessed by more than 3 users at the same time
> then its time to look at RDMS, or if the the data set is massive.
>
>
> All legitimate Magwerks Corporation quotations are sent in a .PDF file
> attachment with a unique ID number generated by our proprietary quotation
> system. Quotations received via any other form of communication will not be
> honored.
>
> CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain
> legally privileged, confidential or other information proprietary to
> Magwerks Corporation and is intended solely for the use of the individual to
> whom it addresses. If the reader of this e-mail is not the intended
> recipient or authorized agent, the reader is hereby notified that any
> unauthorized viewing, dissemination, distribution or copying of this e-mail
> is strictly prohibited. If you have received this e-mail in error, please
> notify the sender by replying to this message and destroy all occurrences of
> this e-mail immediately.
> Thank you.
>