|
|
Posted by Dikkie Dik on 11/19/26 11:47
> I want some code where I present an array of data, and the corresponding
> primary key and let the code work out whether to INSERT or UPDATE it,
Quite simple. If the primary key in your application is numeric, you got
it from the database. Otherwise, how would you know the key value?
If the primary key value is NULL, it is a new record. even if it
contains the same non-key data as an existing record, it is different
anyhow. If you have more than one instance representing one record, you
may look at http://www.w-p.dds.nl/article/wrtabrec.htm for how to fix
that (shamelessly plugging my own article).
> I also want to be able to present the data from a QBF or QBE then be able to
> step through the result set. However I don't want to have to configure the
> DBMS structure - after all most of it is already in the DBMS (OK so not the
> relationships in a MySQL db). It'd be really cool if I could throw SQL
> directly at it *too*.
I think having to configure a mapper is a bad code smell. My biggest
problem today is the dependency across systems. You probably have
encountered situations where file names were in the database, or where
constants in an application referred to enumerations in a database
field. These dependencies cannot be enforced (no one will stop you from
deleting a file if its name is in a database, for example). If you have
a configuration file for a mapper, you introduce *yet another* non
enforceable dependency, along with an untestable system.
But then, I always write my mappings myself. Common code gets into
superclasses and the strict typing (in languages that support it) and
the communication stategies into the wrappers. So definition/lookup
tables become read-only collections, for instance. For each table, I
decide whether I want it to be lazy, greedy, preloadable (you can
"schedule" a record without loading it yet, but it will be loaded at the
first necessary database action), or whatever other combination of lazy
and greedy.
Always remember that a class should encapsulate and hide its internal
structure. If a table strategy would change the interface of its
wrapping collection, it is not a useful wrapper.
Best regards
Navigation:
[Reply to this message]
|