Accesso a livello di record, senza sql

13 Risposte

• O

  oregon

  Super Famoso

  Iscritto da

  nov, 2011

  Messaggi:

  21328

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 04:51

  Penso proprio di no
• 

  Toki

  Moderatore

  Iscritto da

  gen, 2001

  Messaggi:

  3836

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 10:08

  Non puoi, il linguaggio di interrogazione è SQL.
  Perchè non puoi usare SQL?
• M

  MaPa

  Pochi posts

  Iscritto da

  gen, 2020

  Messaggi:

  6

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 10:12

  Se non sbaglio, con la vecchia versione Postres, prima di Postresql, ci si riusciva e speravo che ci fosse ancora la possibilità. Ma neanche con qualche accrocchio tipo gdbm o simili?
• M

  MaPa

  Pochi posts

  Iscritto da

  gen, 2020

  Messaggi:

  6

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 10:16

  Non posso perché il progetto nasce per convertire alcune migliaia di programmi già realizzati che usano questa logica, e cambiare verso sql equivarrebbe a riscrivere la maggior parte dei programmi. Abbiamo già realizzato una cosa simile anni fa creando un modulo che effettua una select * sulla vista logica ordinata, e poi si posiziona con una ricerca dicotomica, ma speravo che in Postresql ci fosse qualcosa di nativo, magari retaggio delle prime versioni, quando ancora si chiamava solo Postgres
• M

  migliorabile

  Super Famoso

  Iscritto da

  apr, 2013

  Messaggi:

  5889

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 12:39

  Stai ragionando in modo SBAGLIATO!
  
  DA NESSUNA PARTE c'e' scritto che tu non possa creare uno STRATO di ADATTAMENTO che CONVERTE le funzioni originarie nell'equivalente SQL di un MODERNO database RELAZIONALE.
  
  In alternativa, continui ad utilizzare il vecchio sistema.
  
  Comunque, la "teoria relazionale dei dati" (Codd) e' del 1969, diciamo 1970, cioe' di 50 anni fa!
  
  Che cosa intendi per "anni fa"?
  5 anni? 10 anni? 20 anni? 50 anni?
  
  Considerazione:
  - PERCHE' non hanno usato un database relazionale?
  - sei SICURO che non abbiamo utilizzato un'ALTRO tipo di database? I database NoSQL NON SONO un'invenzione degli ultimi 5 anni. Esistevano anche 20/30anni fa: database gerarchici, reticolari, ...
  - set SICURO che il passaggio ad un DB relazionale sia la soluzione corretta? Magari ci sono soluzioni piu' intelligenti. NON ESISTONO solo i DBMS relazionali, esistono anche molte librerie per la gestione della persistenza dei dati che magari possono essere ottimi sostituti
• O

  oregon

  Super Famoso

  Iscritto da

  nov, 2011

  Messaggi:

  21328

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 13:30

  I programmi di cui parli che accedono a dei file con cosa lavoravano, scusa?
  
  E perché vuoi usare Postgressql? I dati sono stati esportati su Postgressql?
• A

  asql

  Molto attivo

  Iscritto da

  dic, 2018

  Messaggi:

  515

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 13:35

  Salve a tutti,
  ora "parlo perche' ho la bocca", in quanto non conosco bene Postgres ma solo SQL Server, ma l'articolo, presente nei "nuovi posts" mi ha incuriosito ...
  
  mi viene da pensare che la vecchia soluzione fosse in flat files in qualche modo indicizzati, ed acceduti in questo senso via c-isam o simili... e qui puo' aver senso quanto indicato con un accesso fisico cosi' diretto, anche se i file "dati" potevano contenere ancora dati "cancellati" solo dai file indice, con quindi problematiche di righe phantom che sarebbero poi scomparse con i purge sui file dati...
  
  con SQL Server, scrivendo "parecchio" codice (codice parecchio complicato e necessario di un debug seriamente approfondito, in quanto andrebbe tecnicamente riscritto il layer di accesso fisico ai dati), tecnicamente si potrebbe anche fare, ma... nello stesso modo si avrebbero problematiche di righe phantom come nel caso di accesso a file fisici non ancora "purgati"... e l'impegno nel riscrivere quello che in SQL Server sarebbe il layer dello Storage Engine e' sicuramente piu' che impegnativo, anche senza considerare l'eventuale utilizzo "tradizionale" concorrente del DBMS, dove, brevemente, si aggiungerebbero problematiche di dirty pages, transazioni pendenti e quant'altro...
  
  se proprio tale "implementazione" debba essere necessaria, personalmente farei una "schifezza" che preveda un accesso "tradizionale" tramite una SELECT e quindi proporne il data pump su uno stack diverso dal tradizionale TDS (sempre per SQL Server) che da SQL Server viene poi indirizzato verso il "driver" di interscambio con il client, quindi un layer proprietario che funga da ADO/Ado.Net/SQLNativeClient/ODBC/...
  la mia "risposta breve" ad una richiesta di questo tipo sarebbe probabilmente triviale ed offensiva
  
  saluti omnia
  --
  Andrea
• O

  oregon

  Super Famoso

  Iscritto da

  nov, 2011

  Messaggi:

  21328

  Re: Accesso a livello di record, senza sql

  11 gen 2020, 13:42

  Perché complicarsi la vita con progetti irrealizzabili e non rifare la parte SQL? Sicuramente si impiegherebbe meno tempo e un prodotto stabile e aggiornato.
• M

  MaPa

  Pochi posts

  Iscritto da

  gen, 2020

  Messaggi:

  6

  Re: Accesso a livello di record, senza sql

  13 gen 2020, 01:23

  Salve a tutti, e grazie per le risposte.
  Per essere più chiaro, il progetto nasce per convertire librerie con centinaia di programmi scritti in RPG su sistema iSeries IBM, e ottenere le medesime applicazioni in ambiente windows e linux senza dover riscrivere tutte le procedure: visto il quantitativo, per riscrivere tutto si parla di parecchi anni uomo.
  La conversione del codice, invece, permette di uscire dalla piattaforma iSeries con procedure funzionanti in tempi relativamente brevi, ed effettuare poi gradualmente l'ottimizzazione del codice verso l'sql a procedure funzionanti.
  Il progetto, in una prima versione, l'abbiamo già realizzato convertendo il codice in java, e utilizzando Postgresql come database, ed è attualmente funzionante. Il problema dell'attuale logica di accesso diretto al record è stata risolta, un po' come suggerito da asql, con un modulo di interfaccia che riceve la richiesta, la elabora con istruzioni sql, e restituisce i dati al programma chiamante, e le performance non sono male.
  In questa seconda versione, l'idea è di ripetere la stessa esperienza con un linguaggio compilato, a più basso livello tipo C o C++, per avere migliori performance di calcolo, e la richiesta di una soluzione "nativa" per l'accesso al record nasce per semplificare ed accelerare ulteriormente le prestazioni, sopratutto nel caso di tabelle con un numero rilevante di dati. Ho letto un articolo sulle prime versioni di Postresql, quando ancora si chiamava solo Postgres, in cui era scritto che in questa prima versione non venivano utilizzate le istruzioni sql, ma istruzioni dirette di accesso ai dati sulle singole tabelle, e speravo che fra le pieghe del codice di postresql la possibilità di accesso diretto al record ci fosse ancora.
  Grazie a tutti per l'interessamento e le risposte fornite.
• M

  MaPa

  Pochi posts

  Iscritto da

  gen, 2020

  Messaggi:

  6

  Re: Accesso a livello di record, senza sql

  13 gen 2020, 01:42

  Per rispondere a migliorabile, le procedure sono sicuramente state scritte utilizzando un database relazione: il db2/400, versione del db2 nativa sul sistema iSeries, e integrata direttamente con il sistema operativo. Questo db permette di lavorare sia con istruzioni sql che con chiamate dirette al record, e negli anni passati le procedure sono state realizzate utilizzando i codici operativi di accesso diretto ai dati (posizionamento, lettura, scrittura, aggiornamento, e cancellazione). L'ideale per noi, ma credo irrealizzabile, sarebbe trovare un buon db che, come il db/400, permetta sia le istruzione sql che l'accesso diretto.
  Mi incuriosisce il concetto di "librerie per la gestione della persistenza dei dati": puoi farmi qualche esempio per approfondire?
  Grazie
• M

  migliorabile

  Super Famoso

  Iscritto da

  apr, 2013

  Messaggi:

  5889

  Re: Accesso a livello di record, senza sql

  13 gen 2020, 05:40

  1) esiste DB2 anche per Windows e Linux
  2) passare da Java a C++ ha senso SOLO se il 90% delle applicazioni sono CPU intensive, cioe' fanno un sacco di conti (MILIARDI di operazioni, non centinaia o migliaia: algebra linearea, computer grafica 3D, simulazione,...).
  Per normali applicazioni di tipo 'commerciale' (gestione magazzino, anagrafica, generazione di report, fatturazione, e cose del genere) il passaggio al C++ e' praticamente inutile: migliori le performance FORSE del 1%, ma anche no, introducendo, al contempo, una quantita' di rogne infinita SE non avete programmatori C++ piu' che eccellenti
  3) Java funziona praticamente allo stesso modo (con PICCOLE varianti) su mac, linux e windows. NON E' COSI' per il C++: realizzare un'applicazione C++ che sia compilabile e funzionante su sistemi diversi e' un "bagno di sangue e lacrime". Non ci sono librerie in comune, quelle che ci sono non funzionano esattamente alla stessa maniera, ecc... Per non parlare della difficoltà di realizzare applicazioni con un linguaggio in cui bidogna gestire la memoria 'a mano',...
  4) le basse performance legate all'accesso ai dati NON SI RISOLVONO passando al C++, perche' sono legate al DBMS, MA gestendo MEGLIO i dati: query realizzate meglio, eventuale DEnormalizzazione, creazione di indici, accesso a SET di record e non a singoli record, stored procedures, ecc
  
  E' abbastanza evidente che se vi serve accedere al singolo record vuol dire che non state sfruttando in modo intelligente quello che e' il mestiere di un buon DBMS: SELEZIONARE i dati nei modi piu' complicati possibile. E un DBMS fa questo mestiere in modo piu' che eccellente.
  
  E' gia' un miracolo essere riusciti a convertire l'RPG in Java, non sfidate la sorte . Vi conviene rivedere l'accesso ai dati: e' QUESTO il collo di bottiglia!
  
  In questo tipo di applicazioni, inoltre, l'uso di librerie per la persistenza dei dati e' folle! Si perde un'altra funzionalita' FONDAMENTALE di un DBMS (e ULTRA FONDAMENTALE per le applicazioni) :
  
  A) tomicita'
  C) oncorrenza
  I) solamento
  D) urabilita'
  
  Oltre agli infiniti servizi, applicazioni che possono accedere ad un dbms per fare altre attivita' a cui magari ora non avete pensato, non ultimo l'OLAP (online analytic processing).
• A

  asql

  Molto attivo

  Iscritto da

  dic, 2018

  Messaggi:

  515

  Re: Accesso a livello di record, senza sql

  13 gen 2020, 12:32

  Salve a tutti,
  concordo pienamente con @Migliorabile....
  tanto piu' che il "vostro" progetto prevede comunque una riscrittura (con accesso ai dati via api dirette e molto sporche) che dovra' comunque essere successivamente nuovamente riscritta per utilizzare effettivamente un accesso SQL tradizionale, quindi va riscritto tutto l'accesso ai dati almeno 2 volte, con tutte le problematiche di conflitto inter-versione che tutto cio' puo' causare...
  non so se quanto segue possa avere senso, ma ad esempio SQL Server (lo so, stavate parlando di Postgres) puo' connettersi a DB2 tramite linked server e cio' consentirebbe di progettare la nuova soluzione interrogando DB2 da SQL Server, quindi si potrebbe direttamente gestire l'interfacciamento applicativo in questo senso, e quanto "il tutto" fosse finalmente migrato a SQL Server, si potrebbe buttare giu' DB2... le prestazioni sarebbero penalizzate inizialmente per il carico di query distribuite su server diversi, ma potrebbe pagare, alla fine della fiera... questo pero' sarebbe l'opposto di quanto stai predisponendo...
  
  cio' non toglie che, come anche @Migliorabile riporta, non si avrebbe piu' un accesso ai dati indirizzato a "record", ma a "set di dati" opportunamente gia' filtrati in sede di proiezione... penso tu (@MaPa) possa riconoscere che, malgrado soluzione temporanea, sia MOLTO inefficiente effettuare una SELECT * FROM myMillonRowsTable per farne il data-pump dal mid-layer come anche io avevo indicato e, finalmente, nel codice applicativo fare una

  for ( long row = 0; row < MillionRowCount; row ++) {
      if (outSet[row].ColonnaX == yourParam1 
              && outSet[row].ColonnaY == yourParam2
              && .... ) {
          do_somethng....
          break;
      }
  } 
  

  non possa avere prestazioni esaltanti... capisco le problematiche sia operative immediate che la complessita'/costo/tempo che una riscrittura ex-novo in maniera "corretta" possano comportare, ma non so effettivamente quanto una riscrittura in almeno 2 fasi possa effettivamente pagare...
  sono perplesso
  saluti omnia
  --
  Andrea
• M

  MaPa

  Pochi posts

  Iscritto da

  gen, 2020

  Messaggi:

  6

  Re: Accesso a livello di record, senza sql

  13 gen 2020, 19:57

  Ok, grazie a tutti dei consigli.