Il 23/03/2016 13:29, Mike Sofen ha scritto:
-Original Message-
Thomas Kellerer Wednesday, March 23, 2016 2:51 AM
Jim Nasby schrieb am 11.03.2016 um 17:37:
If the blob is in the database then you have nothing extra to do. It's handled
just like all your other data.
If it's a file in a
> -Original Message-
> Thomas Kellerer Wednesday, March 23, 2016 2:51 AM
>
> Jim Nasby schrieb am 11.03.2016 um 17:37:
> > If the blob is in the database then you have nothing extra to do. It's
> > handled
> just like all your other data.
> >
> > If it's a file in a file system then you
I have another suggestion. How about putting the images in RethinkDB?
RethinkDB is easy to set up and manage, and is scalable and easy (almost
trivial) to cluster. Many of the filesystem disadvantages you mention
would be much more easily managed by RethinkDB.
A while back I wrote a Foreign
Jim Nasby schrieb am 11.03.2016 um 17:37:
> If the blob is in the database then you have nothing extra to do. It's
> handled just like all your other data.
>
> If it's a file in a file system then you need to:
>
> - Have application code that knows how and where to get at the file
> - Have a
Il 23/03/2016 10:50, Thomas Kellerer ha scritto:
Jim Nasby schrieb am 11.03.2016 um 17:37:
If the blob is in the database then you have nothing extra to do. It's handled
just like all your other data.
If it's a file in a file system then you need to:
- Have application code that knows how
On 3/23/16 4:14 AM, Moreno Andreo wrote:
The main goal is to be *quick*. A doctor with a patient on the other
side of his desk does not want to wait, say, 30 seconds for a clinical
record to open.
Let me explain what is the main problem (actually there are 2 problems).
1. I'm handling health
Il 11/03/2016 17:37, Jim Nasby ha scritto:
On 2/22/16 8:40 AM, Moreno Andreo wrote:
Il 18/02/2016 21:33, Jim Nasby ha scritto:
Depending on your needs, could could use synchronous replication as
part of that setup. You can even do that at a per-transaction level,
so maybe you use sync rep most
