Just finished perioperativebleeding.org. An e-learning application designed for anestesiologists, hematologists and allied health professionals who manage, treat, or refer patients in the field of perioperative bleeding management. The physicans can watch lectures and afterwards take short exams to earn CME-credits.
Used technologies:
A very interesting topic, exspecially as many frameworks (f.e. ruby on rails) tend to produce automatically surrogate keys. Lee Richardson tries to advocate surrogate keys in his blog-post. I hate surrogate keys, often calling people using them “M$-Access-Users”. But, to be honest, sometimes, exspecially when mapping OOP-Classes into tables, there is no other way. Best answer to Lee’s post seems to be Ian Batty’s comment. Let me cite one paragraph:
“Personally I am a natural key guy. Saying that, and this is where your example loses credibility, practical experience has shown that for a person there is no natural key, so I create a surrogate. However, if I am creating an entity that has a true unique identifier, that doesn’t change and meets all the other requirements then I will use it.”
Seems to be a very good general advice.
September 9th, 2007
okflo
… wenn man weiss wie, ist es so einfach
require ‘dbi’
dbh = DBI.connect(‘DBI:pg:databasename’)
dbh.disconnect
noch mehr erfahrt man hier