Re^8: Matching alphabetic diacritics with Perl and Postgresql

It is a well known performance issue to minimise the traffic between browser <-> internet <-> application <-> DBMS. I am not sure what else I can say to explain it. The need to clean the data in SQL was because the original user interface did not do it. If I take your advice then either I repeat that mistake, making the project pointless, or I complete transactions to load invalid data to the database before returning an error to the browser to get the user to fix it. Your belief that anything can be done in SQL, surely cannot reasonably extend to pre-empting data entry mistakes? It certainly appears that way.

One world, one people

Comment on Re^8: Matching alphabetic diacritics with Perl and Postgresql

Replies are listed 'Best First'.
Re^9: Matching alphabetic diacritics with Perl and Postgresql by chacham (Prior) on Jun 05, 2017 at 20:22 UTC
It is a well known performance issue to minimise the traffic between browser <-> internet <-> application <-> DBMS. The question is how much is being saved in total, where it is being saved, and at what cost. Especially considering built-in compression, i am not sure you are saving too much. Your belief that anything can be done in SQL, surely cannot reasonably extend to pre-empting data entry mistakes? Actually, with common mistakes, it most certainly can. As long as the mistakes are finite, and can be flagged as mistakes and what the fix is, there's no reason any mistake needs to be fixed manually more than once. With the amount of data you are processing, it most certainly makes sense to do it all in the database, and only ask the user for input where a new mistake pops up. Plus, by doing it in the database, should there be a service disruption, the state is saved and the data need not be transferred a second time, saving a lot of work from the user. Implementing it in the UI likely means restarting the process any time anything fails, and allowing zero collaboration, whatsoever.	[reply]

Replies are listed 'Best First'.

Re^9: Matching alphabetic diacritics with Perl and Postgresql
by chacham (Prior) on Jun 05, 2017 at 20:22 UTC

It is a well known performance issue to minimise the traffic between browser <-> internet <-> application <-> DBMS.

The question is how much is being saved in total, where it is being saved, and at what cost. Especially considering built-in compression, i am not sure you are saving too much.

Your belief that anything can be done in SQL, surely cannot reasonably extend to pre-empting data entry mistakes?

Actually, with common mistakes, it most certainly can. As long as the mistakes are finite, and can be flagged as mistakes and what the fix is, there's no reason any mistake needs to be fixed manually more than once. With the amount of data you are processing, it most certainly makes sense to do it all in the database, and only ask the user for input where a new mistake pops up. Plus, by doing it in the database, should there be a service disruption, the state is saved and the data need not be transferred a second time, saving a lot of work from the user. Implementing it in the UI likely means restarting the process any time anything fails, and allowing zero collaboration, whatsoever.

[reply]