Function Speed vs UI Function Speed

Started by Susan Hurstover 5 years ago2 messagesgeneral
Jump to latest
#1Susan Hurst
susan.hurst@brookhurstdata.com

Is there a significant difference in execution speed between similar
functions that do the same DML but differ in the extra validations and
messaging that are required for providing feedback to UI users?

For example, a batch load script that inserts multiple rows into a table
may call an insert function within a cursor to populate each row into
the target table. Meanwhile, a non-technical business user may want to
create only one entity via a UI. However, the UI must have validations
and helpful messages to to user so the insert works....or won't, but at
least user would know what they need to do differently to get to a
successful outcome.

Typically, the teams that I've worked on typically create the bare
functions that will get the job done but later we have to come back and
make new functions specifically for UIs. BTW....I'm a firm believer in
having the database protect itself and not totally depend upon the
application layer to protect data. Anyone with database access can
bypass a UI and still corrupt data unintentionally (incomplete WHERE
clause, for example).

Now I wonder if it would be prudent to create the UI ready functions
only and use those same functions for batch loads or any other process
that needs to be done in bulk. I'm not sure about the performance impact
of that.

Any insights or ideas?

Thanks for your help!

Sue

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Susan E Hurst
Principal Consultant
Brookhurst Data LLC
Email: susan.hurst@brookhurstdata.com
Mobile: 314-486-3261

#2Joshua D. Drake
jd@commandprompt.com
In reply to: Susan Hurst (#1)
Re: Function Speed vs UI Function Speed

On Mon, Aug 31, 2020 at 10:32 AM Susan Hurst <susan.hurst@brookhurstdata.com>
wrote:

For example, a batch load script that inserts multiple rows into a table
may call an insert function within a cursor to populate each row into
the target table. Meanwhile, a non-technical business user may want to
create only one entity via a UI. However, the UI must have validations
and helpful messages to to user so the insert works....or won't, but at
least user would know what they need to do differently to get to a
successful outcome.

I think you have both. You don't want the round trip of having the database
throw an exception in this example. So yes, you have the validations within
the UI for a higher level of success before submission. However, you still
want the proper constraints on the database itself as it is the canonical
source for your data. Further, you never know when someone else is going to
connect to the database in something that isn't your application.

JD