RE: Metadata-driven data retrieval
From: Cowboy (Gregory A. Beamer) - MVP (NoSpamMgbworld_at_comcast.netNoSpamM)
Date: 01/17/05
- Next message: djc: "Re: whats recommended way to handle this? no records"
- Previous message: Cowboy (Gregory A. Beamer) - MVP: "RE: Handling multiple result sets"
- In reply to: Craig Wagner: "Metadata-driven data retrieval"
- Next in thread: Sahil Malik: "Re: Metadata-driven data retrieval"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 Jan 2005 08:57:05 -0800
Even with homegrown data solutions, you are best to have some form of
centralized configuration. This could be as simple as a config file for
storing database connection strings, but may require using something like
MSDE for configuration data (and an installer that installs both).
Hitting a variety of data sources is quite easy when you can bring it down
to some form of commonality. in the case of the MS world, this means having
either an OLEDB provider or being able to use ODBC.
Since you are mapping more than just database strings, you will likely
require a custom solution. Mapping fields to metadata is not a problem,
overall, but finding commonalities across client base will save you time in
the long run. Finding, for example, particular packages that you will work
with.
The other way to solve this issue is your application has some form of
custom interface to translate needs from their system to yours. In essence, a
smart driver for their data. You can do this with mapping, of course, but a
more efficient manner would be some form of compiled query on their system
(stored procedure, Access query, etc.) that returns the result set in the
proper form. You may end up writing much of this, but it will save having to
make a tool that is "one size fits all".
--- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA *************************** Think Outside the Box! *************************** "Craig Wagner" wrote: > We need to develop a component that will live at our client sites and > interrogate their database. Problem is, the clients use a variety of canned and > home-grown packages to develop their application. > > Our thinking is that we could develop a metadata-driven data retrieval > component. We would, with the client's help, analyze their data storage and > configure the component to pull the correct values from the correct row(s) and > column(s). In some cases we may need to combine values (e.g. full name is made > up of Employee.FirstName, a space, and Employee.LastName). > > Has anyone developed such a component? Or know of one available for > download/purchase? > > TIA > --- > Craig Wagner, craig.wagner(at)comcast.net > Portland, OR > > "Don't ban high-performance vehicles, ban low-performance drivers!" >
- Next message: djc: "Re: whats recommended way to handle this? no records"
- Previous message: Cowboy (Gregory A. Beamer) - MVP: "RE: Handling multiple result sets"
- In reply to: Craig Wagner: "Metadata-driven data retrieval"
- Next in thread: Sahil Malik: "Re: Metadata-driven data retrieval"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
