Re^7: Matching alphabetic diacritics with Perl and Postgresql

[chacham]

moving it downward into the database is going in the wrong direction

I disagree. If anything, as the data can be manipulated from more than one location, the best place is "downward" in the rdbms. That is the one centralized location for your data. Anything else adds more code that needs to be kept in sync, reinvented, and allows for inconsistencies.

creating not only unnecessary internet communication

No matter what, you have to communicate with the database, and the communication at some point goes over the Internet anyway, so you have not saved anything. Even if you mean that the UI can handle some of the manipulation without communication, that would include none of the validations that require the database. I do not see how you are saving anything significant communication-wise.

but unnecessary communication between application and DBMS.

I fail to understand what you even mean here, sorry. Communication between the application and the database in the single most important factor in a data driven application. In many cases, the drivers automatically compress the data for you as well.

Ideally, data should be cleaned before it gets to the database.

You seem to be viewing the database as a dumb data container instead of the complex data master that it is. The database is made for this. There are keywords and functions specifically designed to help you clean and manipulate your data. To do it elsewhere first and then put it in the database, is reinventing the database outside of it.

[anonymized user 468275]

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.

[chacham]

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.