2008/2/13, Mark Johnson <[EMAIL PROTECTED]>: > Phil Longstaff wrote: > > The slot_id is used to provide a unique primary key. I don't know if it > > would work to have the slots table have *no* key, but have an index on > > the obj_guid field. The obj_guid field can't be the primary key because > > I believe a primary key needs to be unique. Mark? > > > > > Yes, a primary key does have to be unique. I can't think of any > requirement that a table have a primary key though. It is generally > good practice. You could have an index on the guid field. >
Derek can confirm this: GUID is unique for any object using in QOF, then you can use it as the primary key, the control of unique GUID will be responsability of GnuCash/QOF and that GUID is almost imposible to be duplicated in other instance of GnuCash accessing to the DB, even if it is simultaneous. Just take in acount that GUID is a string, then it will represent more work for the DBMS to check for the unique constraint. > In my benchmarking, I was thinking I might create such an index to see > if it helped. I haven't got that far though. I will be posting my > results so far (i.e. without any additional indices) soon (hopefully > later today). Obviously, they can't include the complete series of > queries for PostgreSQL. I have done MySql and SQLite, but need to run > the partial series for PostgreSQL. > > Mark > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE) _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
