For Stene, or anyone who can answer his statements

[Sten-Erik Björling]

Dear Das,

You have covered the table class yourself and Doug covers the main arguments for SQL Workers as well. One additional point for SQL workers in the context of Postgres is that each instance of these workers can be delegated to different CPU cores which effectively distribute the workload more effectively.

I use table classes mainly for standard operations on singular tables such as insert, deletion and updating etc. The more extensive logic is handled by a layer above the table classes in the form of ”data objects” - object classes responsible for management of individual tables and ”process objects” - objects responsible for more extensive and complex operations - more to be regarded as more complex business rules and processes. Creating an invoice is one such example. By using objects one can simplify the transformation of parts of your system from using DB access to get data to using REST etc. for data access without having to disrupt the overall architecture of your system - using approaches from contractual programming.

Session pools are also usable in a fat client scenario - not only for application servers. In my programming I aim at keeping the number of used resources down as much as possible to keep memory use down - since one can presume that ones system later on can be the basis for web applications. A session represents in the case of Postgres an instance of Postgres being started on the server - which takes memory and for other DB environments eventual licensed nodes. By effectively using session pools the utilisation of individual DB sessions on the server can be maximised - even if you have several hundred simultaneous users on your system these users might only demand about 5-10 DB instances on the server instead of hundreds of mostly inactive sessions. Using session pools also in fat client can prepare your code for these eventual future extensions of your system.

Another advantage is that one can organise the session pools into different types - I use separate pools for read-write, read-only and eventual analysis where the sessions from these different pools have different settings for preparing them for read-only, result set sizes etc. Using a session that allows for writing to the DB demand more preparations at the DB side, read-only access demands less. And since most operations are read only on a system one can save processor cycles on the server which can be important for future deployments.

Hope this clarifies things, take care, all the best…

Stene

_______

> 26 jan. 2018 kl. 02:52 skrev Das Goravani <das at Goravani.com>:
> 
> Dear Stene, you wrote:
> 
>> On Jan 24, 2018, at 10:31 PM, Sten-Erik Björling <s-e.bjorling at enviro.se> wrote:
>> 
>> I do not use schema classes at all to represent tables in a database - I use the approach for dynamically create a unified table class template from the database model at the database itself presented by Dan Ridinger at a Euromnis event a number of years back. This to prevent having potential version conflicts later on. The resulting table class template from this operation is then used to create a row var template that will be copied during the code execution.
> 
> 
> Question: The table class you create exists only in memory and is a row of column definitions taken from reading the same from the existing database, am I correct? 
> 
> 
> Stene:  Presented these approaches and some others in regard to session pools, SQL workers and push approaches using object centric approaches at the German conference 2017.
> 
> 
> Question:  Can you please write the main reasons why you urge for 1. Session Pools  2. SQL workers.   In my understanding SQL workers are only necessary if you have long running SQL operations and session pools are only necessary if you want to use more than one session at a time, am I correct?
> 
> 
> Thank you for your time,
> 
> Das Goravani



Sten-Erik Björling
Enviro Data
Kyrkogatan 5A 2 tr
SE-972 32  Luleå
Sweden

E-Mail: s-e.bjorling at enviro.se
Mobile: +46-70-655 11 72
Wire: @stenerikbjorling
Skype: stenerikbjorling
iChat: stene at mac.com
FaceTime: stene at mac.com
Hotmail / Messenger: stenerikbjorling at hotmail.com
GMail: stenerikbjorling at gmail.com

______

This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.

Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.