Sure, First, let me use this example to demonstrate the problem I'm trying to point out, and then I'll explain point out to details of the principles I'm recommending in the db domain.
Including behaviour in database is a choice given to you by most of the product vendors. It may or may not lead to issues in maintainability, and its correct use requires a lot of experience. Imagine having a set of database tables, along with some stored procedures. In your product/information system you may manage this combination, while leveraging the benefits of performance. What if you were using PostgreSql and you decided to share your database design with others? Your table design would be expressed in DDL, which would be highly portable to other databases like Sql Server, or Oracle. Your stored procedures on the other hand are written in pl/pgsql, which does not mean anything in Sql server world. It can be ported fairly easily to Oracle, but that is still porting. It may get worse, since modern rdms products allow you to plug/in languages to write stored procedures, so it may be python, C# or java you have in your hands, that contains behaviour. This is the problem I'm talking about. Now to the way this is handled in db world In this case, you'd be able to carry your table structure to other dbs (with some help from tools and some tweaking), because the DB domain keeps table structure and stored procedures separate. Many design tools will read a db schema from a database, and generate sql statements to generate the same tables in another db server. They can't however, transfer the stored procedure code. If you were to join both table structure statements and stored procedures in the same formalism, you would not be able to move them around, unless every db implements every stored procedure language/runtime. So the db domain already does what I suggest we do. It keeps data and behaviour separate. There is DDL and there is stored procedures. Every time you mix them, you have issues in sharing them with others, which is what openEHR is all about! Regards Seref On Wed, Mar 23, 2011 at 11:41 AM, Bert Verhees <bert.verhees at rosa.nl> wrote: > Some people I work with ask for this feature, I find it hard to explain > why this should not be done. > > Can you compare it with Stored Procedures in database-applications which > have the risk of bringing software-logic (f.e. from business-tier) to > the database-tier, and there for often is regarded as bad design because > requirements/concepts get mixed up? > Although from performance point of view, stored procedures are often the > best performing modules in an application. > > Anyway, most RDB's support stored procedures. Why would that be? I hope > not to encourage bad design? > > Am I coming close to understanding of your criticism? > > Bert > > Op 23-03-11 12:07, Seref Arikan schreef: >> Also look at heartbeat is the problem here. My criticism stands, for >> every case your rules/guidelines go beyond data. >> >> Best Regards >> Seref >> >> >> On Wed, Mar 23, 2011 at 11:05 AM, Bert Verhees<bert.verhees at rosa.nl> >> ?wrote: >>> The idea is to implement guideline/rules etc in Archetypes. >>> In this way you can force software to look at some conditions if some other >>> conditions are met. >>> >>> As I gave an example: If bloodpressure> ?value -->> ?also look at heartbeat. >>> >>> Bert >>> >>> >>> Op 23-03-11 00:32, Seref Arikan schreef: >>>> Greetings, >>>> I have a single question about this particular requirement/idea: why? >>>> >>>> Archetypes are model artefacts. That is it. They are supposed to >>>> describe domain models in a certain way. Behaviour or software that >>>> uses those models is a completely different thing. I can understand a >>>> constraint which references another one for defining a valid interval >>>> etc, but how on earth something like forcing a user for another entry >>>> is going to be handled during implementation? How would one express >>>> this in common formalisms like XML? >>>> >>>> I could understand a suggestion to use ADL to express rules regarding >>>> the archetypes, but that should be a formalism leaving in a separate >>>> space, which may be linked to archetypes, which >>>> only-contain-constraints-on-RM-types. >>>> >>>> Please keep behaviour our of models in ADL specifications. >>>> >>>> Regards >>>> Seref >>>> >>>> >>>> On Fri, Mar 18, 2011 at 8:10 PM, Bert Verhees<bert.verhees at rosa.nl> >>>> ? wrote: >>>>> Thanks, Thomas, for your reply. There is more to it then I initially >>>>> thought of. >>>>> >>>>> I am not very familiar with XPath. Best is to wait for more information >>>>> on the specs. >>>>> This is enough for now, to let customers give something to think about. >>>>> >>>>> Bert >>>>> >>>>> On 16-03-11 19:32, Thomas Beale wrote: >>>>>> Hi Bert, >>>>>> >>>>>> I hope to get back on the spec in the next couple of weeks. With respect >>>>>> to your specific question below, can you be a bit more precise? There >>>>>> are ways to express this kind of thing, but we need to be clear on >>>>>> distinguishing references to: >>>>>> >>>>>> ? ? ?* elements in the same archetype - as in a rule like: >>>>>> ? ? ? ? ? ?o /path/to/systolic/pressure/value> >>>>>> ? ? ? ? ? ? ?/path/to/diastolic/pressure/value >>>>>> ? ? ?* elements in data elsewhere in the same EHR like: >>>>>> ? ? ? ? ? ?o $date_of_birth:ISO8601_DATE ::= query(?ehr?, >>>>>> ?date_of_birth?) >>>>>> ? ? ? ? ? ?o this is still being finalised, so don't depend on it; >>>>>> ? ? ? ? ? ? ?however it is the left hand side that matters, i.e. >>>>>> ? ? ? ? ? ? ?$date_of_birth >>>>>> ? ? ?* environmental values, like >>>>>> ? ? ? ? ? ?o $current_date >>>>>> ? ? ? ? ? ?o $current_time >>>>>> >>>>>> Some of this is still being finalised, but the general syntax will look >>>>>> like Xpath and the object model will be what you would expect from that. >>>>>> >>>>>> - thomas >>>>>> >>>>>> On 10/03/2011 15:48, Bert Verhees wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am sorry, but I am to busy to read all the discussions on future >>>>>>> ADL-versions. >>>>>>> So, now I have a small question, which possible is already explained, >>>>>>> >>>>>>> Is it possible to write conditional constraints in future ADL? >>>>>>> >>>>>>> The question is about implementing care-protocol into an archetype. >>>>>>> >>>>>>> For example, if blood-pressure is> ? ? ?200, force to use another entry, >>>>>>> for >>>>>>> example also look at heartbeat >>>>>>> >>>>>>> Is there any idea when this new specifications will be in final >>>>>>> version? >>>>>>> >>>>>>> Thanks >>>>>>> Bert >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openEHR-technical mailing list >>>>>>> openEHR-technical at openehr.org >>>>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>>>>>> >>>>>> * >>>>>> * >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openEHR-technical mailing list >>>>>> openEHR-technical at openehr.org >>>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical at openehr.org >>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>>>> >>> >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
