> Leonel Nunez wrote: >>> I think the arguments for keeping stuff inside the database are >>> (a) far easier to maintain transactional semantics for insert/delete, >>> and (b) easier to serve the data out to clients that aren't on the >>> same machine. You aren't going to find a performance win though. >>> >> >> (c) easy to replicate > > I don't follow that. Suppose your database minus images is 3 GB, and > your images are another 50 gigabytes. Which is easier to replicate, 3 > or 53? Put the images on a file server, separate from the DBs - no need > to replicate them.
yes 3GB are *faster* han 53 gb but is the same as easy as 3 or 100 > And if you do want to copy (e.g., your replicated DB > is in a remote location), you can do a simple file system copy to the > corresponding remote file server. this is done with automatic replication as the data is inserted, deleted or updated. When I say data I mean records , images, pdfs and all the objects I use > >> (d) easy to load balancing > > If you're load balancing, both databases are in the same location, > right? In which case you only need one set of images on a central file > server. > the bigger data are the images so 1 set of images is not a real solution for me. with all the data stored on the database gives me more scalability, consistency, flexibility than putting the "files" on the disk and "data" on the database > -- > Guy Rouillier > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > Leonel ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
