Skip to content

Entity naming across schemas

Jump to bottom
Sandeep Dolia edited this page Apr 4, 2016 · 7 revisions

There is no pattern / theory that recommends how we should name the entities however here are some of the driving factors, given our project

  • Having the same name (for instance Organization across the scheams , help us in having the common routines that works across the schemas). It could be reports, stored procedures or any views that we would like to execute across the schemas, for any furture purposes.

  • We don't have to maintain any mapping tables across the schemas - as the names are consistent across all the schemas.

    • @eric-jahn's comment: I can provide a couple examples where the name changes, but the entity is effectively the same thing. In the 2010 and 2004 versions of the schema, "project" used to be called "program". If we ever start to add other funding sources, some of them don't use "organization" and use "agency" instead, but they are equivalent. So we might have to support mappings at some point anyway, to accommodate semantic equivalents.

  • All the entities hold the same kind of data (for instance, Organization entity in base schema and Organization entity in version specific schema do not differ in what kind of data they maintain, although vary in number of fields) For instance, fields in enrollments entity in 2014 schema and 2015 might vary - given the schema changes, but we still maintain the same name.

  • I beleive, maintaining a different name like dedup_organization, under base schema, is only for conveinience purposes and doesn't have any technical significance.

    • @eric-jahn comment: Appending dedup or not to the beginning is fine either way with me. And we can make it so the default is to map to the same name in the versioned schema, unless overriden by a mapping. Then we get the best of both worlds.

  • @Sandeep : I'm proposing something like this: We should have a DedupClientDaoImpl which would extend ClientDaoImpl. The DedupClientDaoImpl will take care of persisting any table(client or dedup_client) in the base schema and this way we should be able to persist to the base schema via persisting into version specific schema. Additionally, We can always query the base schema by its deduped_client_id to uniquely identify a client. Like I said, I'm not married to (dedup_client or client) the only reason why I'm proposing a 'dedup' word is to easily identify deduped tables.

Clone this wiki locally