|
|
Posted by Jack Vamvas on 09/30/99 12:00
Stored Procedures are the ideal -for all the benefits mentioned above. But
in reality , some sort of Object method whereby the
user can dynamically SELECT the columnns can be more effective. A typical
example , might be an application that stores
matterials information , for example the airlines industry. In that
situation, you've potentially got hundreds of attributes that could be
assigned
to a given material, which then need to be selected from different
perspectives.
--
Jack Vamvas
___________________________________
Search IT jobs from multiple sources- http://www.ITjobfeed.com
"Mike Husler" <Michael.P.Husler@noaa.gov> wrote in message
news:fmiq44$tin$1@news.nems.noaa.gov...
> We have a SQL Server database that can accept data from several different
> projects throughout our lab. Is it better to (1) let each developer
> create their own prepared SQL statements for inserts or to (2) hide the
> schema from them and have them call stored procedures or views to get the
> data into the database?
> So for example, in the 1st case, the developer's code (e.g. PERL w/
> DBI/DBD) would prepare/execute:
>
> INSERT INTO table (col1,col2,col3) VALUES (1,2,3)
>
> and in the 2nd case they would prepare/execute:
> EXEC sp_insertdata, @val1 = 1, @val = 2, @val3 = 3
>
> .. and the stored procedure does the insert.
>
> The main goal here is to isolate the developer from knowing the database
> schema. Only the 'database team' knows the schema and then any changes
> are done in one place (i.e. the view/stored procedure) instead of one or
> many external applications.
>
> In the 2nd case, the schema is invisible to him/her but if a column was
> added to 'table', they would have to change their stored procedure call
> all the same.
>
> If there is there an easier way to do this please advise. Some of our
> inserts are into tables of 100 or more columns (time-based data) and the
> cadence can be sub-second.
>
> Any help appreciated.
>
> Michael Husler
Navigation:
[Reply to this message]
|