[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

is ruby only usable for pictures not for documents ?

Herman Müller

6/3/2009 7:40:00 PM

Hi Ruby-Community,

I searched the last days a lot for finding a plugin or tutorial for
storing documents (like pdf, doc, dox, with mime-type etc.) into the
database, the only thing I found was plugins or howtos for storing
pictures (attachment_fu etc.).

Normally when you try to develop professional solutions you have to
store documents like contracts etc. and something else into the
database.

But it looks like, that RoR is only good for storing pictures, do
sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
with full-text-indexing?

Thanks ahead,

Regs

Herman
--
Posted via http://www.ruby-....

6 Answers

Ben Bleything

6/3/2009 8:06:00 PM

0

On Wed, Jun 3, 2009 at 12:39 PM, Herman M=FCller <dgwauss@web.de> wrote:
> Normally when you try to develop professional solutions you have to
> store documents like contracts =A0etc. and something else into the
> database.

Well, you have to store them *somewhere*. I'd argue that the database
is not a very good fit. You can't query against a blob.

> But it looks like, that RoR is only good for storing pictures, do
> sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
> with full-text-indexing?

Generally it's better to store the files on the filesystem and paths
in the database. As for indexing, you'll need to devise a method to
extract meaningful data from your documents and store that data in the
database.

Ben

Chris Shea

6/3/2009 8:27:00 PM

0

On Jun 3, 1:39 pm, Herman Müller <dgwa...@web.de> wrote:
> Hi Ruby-Community,

Hi.

> I searched the last days a lot for finding a plugin or tutorial for
> storing documents (like pdf, doc, dox, with mime-type etc.) into the
> database, the only thing I found was plugins or howtos for storing
> pictures (attachment_fu etc.).

attachment_fu can store whatever you give it. The examples for the
has_attachment method includes ones like: has_attachment :content_type
=> 'application/pdf'

> But it looks like, that RoR is only good for storing pictures, do
> sombody knows howt to store *.pdf, *.docs etc. into the database?

Ruby on Rails has no intrinsic issue with storing PDFs in a database,
or any intrinsic strength for storing images. I'd suggest reading the
documentation for attachment_fu to see how to do it.

HTH,
Chris

Gregory Brown

6/3/2009 8:35:00 PM

0

On Wed, Jun 3, 2009 at 4:30 PM, Chris Shea <cmshea@gmail.com> wrote:

> Ruby on Rails has no intrinsic issue with storing PDFs in a database,
> or any intrinsic strength for storing images. =A0I'd suggest reading the
> documentation for attachment_fu to see how to do it.

Maybe we should ship Prawn with an Sqlite database? ;)

Robert Klemme

6/3/2009 10:08:00 PM

0

On 03.06.2009 22:05, Ben Bleything wrote:
> On Wed, Jun 3, 2009 at 12:39 PM, Herman Müller <dgwauss@web.de> wrote:
>> Normally when you try to develop professional solutions you have to
>> store documents like contracts etc. and something else into the
>> database.
>
> Well, you have to store them *somewhere*. I'd argue that the database
> is not a very good fit. You can't query against a blob.

A database gives you a few things which may be important for some projects

- it is transactional, e.g. you can do safe updates in concurrency
situations and you can make sure that a set of changes is done
atomically. This helps keeping application data consistent.

- you have all your application data in one place,

- which is especially useful for backups; RDBMS usually come with some
form of backup solution, some of those are even capable of doing hot
backups, i.e. while the application is active.

- professional databases come with a lot more features that can be
important for a business (replication, security...).

>> But it looks like, that RoR is only good for storing pictures, do
>> sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
>> with full-text-indexing?
>
> Generally it's better to store the files on the filesystem and paths
> in the database. As for indexing, you'll need to devise a method to
> extract meaningful data from your documents and store that data in the
> database.

That extraction and indexing part can be done by some databases for some
document types (full text indexing, features for spatial data). Of
course, you pay a price when you place documents in the database
(license fees, no direct access to docs) but one should be aware of the
options.

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestprac...

Phlip

6/4/2009 1:53:00 AM

0

Ben Bleything wrote:
> On Wed, Jun 3, 2009 at 12:39 PM, Herman Müller <dgwauss@web.de> wrote:
>> Normally when you try to develop professional solutions you have to
>> store documents like contracts etc. and something else into the
>> database.
>
> Well, you have to store them *somewhere*. I'd argue that the database
> is not a very good fit. You can't query against a blob.

The database is not a good fit for large binary files because databases and
filesystems are architected and tuned for completely different performance
envelops. Databases work best relating long lists of short data. Filesystems
work best manipulating short directories of huge files.

Further, a web server can serve those files without bothering Ruby. 'nuff said!

Put your documents on the filesystem and store their paths in your database. The
Rails plugin called Paperclip shows how to do this, with a system that would be
very hard to improve on.

--
Phlip

Len

3/29/2010 4:24:00 AM

0

Hi All,

Sorry for delay in replying my post as I was away in the weekend
Thanks for your great helps and your suggestions

I will try it out

Regards
Len