Re: managing tablespaces like files? - Mailing list pgsql-general
| From | Sam Carleton |
|---|---|
| Subject | Re: managing tablespaces like files? |
| Date | |
| Msg-id | 8d38ca0a1003092059o96e2413y628a41e1ae2b57c1@mail.gmail.com Whole thread Raw |
| In response to | managing tablespaces like files? (Sam Carleton <scarleton@miltonstreet.com>) |
| List | pgsql-general |
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@magwerks.com> wrote:
On 3/9/2010 12:45 PM, Sam Carleton wrote:For more comments you will have to explain what the other files and folders are doing.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
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.
pgsql-general by date: