Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#2 Demonstrate separate schema for additional customer fields

open
nobody
None
5
2008-01-03
2008-01-03
Jeff Kowalczyk
No

Per #ledgersmb conversation with metatrontech:

One may have a third-party app, with tens of fields in the table corresponding to LSMB customers. Question asked where to store these additional fields.

"Add another schema and create a database tables for the fields. Then these could be linked against customer.id for now, and when you upgrade they could be moved to entity_credit_account.id. You should reference the tables by the full path, i.e. schema_name.table_name."

This bug requests that this advice solving a very common problem be codified into a FAQ or HowTo, perhaps with a SQL script to create the schema and interschema relations according to best practices and name conventions, for the benefit those without extensive SQL knowledge.

The integrator could customize the SQL script with their particular custom fields in the additional schema.

Proliferation of this style of additional data storage of may lead to smoother and better-documented migration to 1.3 for customized datasets.

Thanks.

Discussion

  • trevor
    trevor
    2008-01-24

    Logged In: YES
    user_id=1783241
    Originator: NO

    I consider this to be quite important/beneficial as well. I have made numerous extensions to the customer, vendor, and part tables. Right now, it is transparent. But when DB upgrades/changes occur, I will be seriously affected. If I knew the 'best' way to do this to mitigate migration problems in the future, then I could save myself some headache and time.