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.