Thread: Standard schemas for common features?

Standard schemas for common features?

From
gvim
Date:
I'm putting together a database for a web project which has a lot of HR components which I imagine are fairly
standardisedso, to avoid re-inventing the wheel, is there a source of standard, downloadable schemas for common
projects?

gvim

Re: Standard schemas for common features?

From
Chris Browne
Date:
gvimrc@gmail.com (gvim) writes:
> I'm putting together a database for a web project which has a lot of
> HR components which I imagine are fairly standardised so, to avoid
> re-inventing the wheel, is there a source of standard, downloadable
> schemas for common projects?

One might imagine so...

The last time I was looking for such (albeit not specifically in an HR
context), what I found was that there were enough local complications
resulting from the vagaries of local company structure that the bits
that could be treated as "standard" were minor in comparison to the
specialized structures.

There are things that get pretty ugly when you try to go "standardised":

 - You're sure to use addresses...  Will they be:
   a) Something localized to your country, complete with constraints
      encoded in the schema?  (e.g. - as with telephone number formats,
      zip codes, states, and such)
   b) Something intended to be generic across multiple countries?
      In that case, the schema generally CANNOT enforce country-specific
      rules, thereby increasing the risk of the data turning into crud

 - What normalization do you do concerning employees and their
   attributes?

   It's attractive to keep the model simple, but if there are legal
   requirements to track information about applicants (who may never
   actually become employees), simple mayn't be an option.

 - What genders do you store?  Male/Female actually *isn't* specific
   enough, with the simple counterexample where someone fails to specify
   a value.

   (Which oughtn't be controversial even to folk that might be
   uncomfortable with more, erm, "outre" gender options...)

 - You operate in some legal jurisdiction.  (or perhaps several?)

   Different jurisdictions assortedly require or forbid the collection
   of particular pieces of information, and may require that to be
   encoded into your schema.  What is allowed/forbidden will vary, and
   if you operate in multiple jurisdictions, there's some need to follow
   *all* of the legal impositions.

A generic schema leads to considerable risk of allowing in nonsense
data, whilst *my* non-generic schema is quite likely to be terrible for
*you* when you have somewhat different business requirements.

There are enough conflicts available across these issues to mean that
you shouldn't just take the first sample schema you might happen across.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','linuxfinances.info').
http://linuxfinances.info/info/slony.html
Always remember that you're unique, just like everyone else.