Hi,
Maybe not completely the wright place to ask but... I have this schema
design question (db is postgres of course). I have a couple of classes with
attributes. The only goal is to search the object that I want to find (which
is stored on the harddrive).
I have hundreds of classes that are sim
> Maybe not completely the wright place to ask but... I have this schema
> design question (db is postgres of course). I have a couple of classes
> with attributes. The only goal is to search the object that I want to
> find (which is stored on the harddrive).
> I have hundreds of classes that ar
Hi Adam,
Thanks for the fast reply. What should inherit from what? Class A (e.g.
'todo item') is certainly not derived from property X (e.g. 'startdate').
Class A version 2 has different properties (some are removed, others are
added). Can you elaborate / say I'm wrong / give an example ? Thanks,
On Sun, Aug 19, 2007 at 03:19:52PM +0200, mark overmeer wrote:
> Hi,
>
> Maybe not completely the wright place to ask but... I have this
> schema design question (db is postgres of course). I have a couple
> of classes with attributes.
Danger, Will Robinson! Danger!
The DBMS way of looking at
On Sun, Aug 19, 2007 at 11:12:16AM -0700, David Fetter wrote:
> There's your mistake. EAV is not performant, and won't become so.
It sort of depends. I put all the EXIF information for my image gallery into
an EAV table -- it was the most logical format at the time, although I'm not
sure I need a
On Sun, Aug 19, 2007 at 08:26:58PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 19, 2007 at 11:12:16AM -0700, David Fetter wrote:
> > There's your mistake. EAV is not performant, and won't become so.
>
> It sort of depends. I put all the EXIF information for my image
> gallery into an EAV tab
Nik, you may be underestimating just how much performance can be obtained
from a single database server. For example, an IBM p595 server connected to
an array of ds8300 storage devices could reasonably be expected to provide
several orders of magnitude more performance when compared to commodity
ha
Hi,
2007/8/19, Steinar H. Gunderson <[EMAIL PROTECTED]>:
>
> As a general database design paradigm, though, I fully agree with you.
> Databases are databases, not glorified OO data stores or hash tables.
I don't want to use it as an OO data store, I use the filesystem for that.
The intended use i
Andrew,
I'd say that commodity systems are the fastest with postgres - many have seen
big slowdowns with high end servers. 'Several orders of magnitude' is not
possible by just changing the HW, you've got a SW problem to solve first. We
have done 100+ times faster than both Postgres and popul
On Sun, Aug 19, 2007 at 10:13:08PM +0200, mark overmeer wrote:
> Hi,
>
> 2007/8/19, Steinar H. Gunderson <[EMAIL PROTECTED]>:
> >
> > As a general database design paradigm, though, I fully agree with
> > you. Databases are databases, not glorified OO data stores or
> > hash tables.
>
> I don't w
On Sun, Aug 19, 2007 at 11:41:15AM -0700, David Fetter wrote:
> Unless your records are huge, that's a tiny database, where tiny is
> defined to mean that the whole thing fits in main memory with plenty
> of room to spare. I guarantee that performance will crash right
> through the floor as soon a
Folks,
Please remove pgsql-jobs from your CC list with this thread. That list is
ONLY for employment ads. Thank you.
> Nik, you may be underestimating just how much performance can be
> obtained from a single database server ...
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
-
Hello,
Just to note something interesting on database scalability: i'm not sure
whether your database is used for processing or just data lookup, but if
it's used for data lookup, look into memcached -- it's a really scalable
caching system which can reduce your database load a lot.
I know a lot
> However, it still doesn't answer my question about the EV model (where
> each attribute is given its own table).
Do a TABLE(object_id INT, attribute STRING, value STRING) if you just
want to be able to search for objects by an attribute. But better yet
look at one of the thousand object persi
On 8/19/07, Luke Lonergan <[EMAIL PROTECTED]> wrote:
>
> Andrew,
>
> I'd say that commodity systems are the fastest with postgres - many have
> seen big slowdowns with high end servers. 'Several orders of magnitude' is
> not possible by just changing the HW,
>
Going from one or two SATA disks to
15 matches
Mail list logo
