Il database relazionale va in pensione, avanza il movimento NOSQL

Negli ultimi anni le applicazioni sono diventate sempre più "affamate" di dati. Dati in grandi quantità, di diverse tipologie e ad una frequenza sempre più elevata. Questo fenomeno, qualificato con il nome di BigData, ha costretto Amazon e Google a ridefinire il trattamento delle informazioni e a proporre architetture alternative in grado di garantire un efficace scale-out.
La condivisione delle soluzioni da loro trovate ha portato poi alla realizzazione di una serie di database che non utilizzano il modello relazionale per il trattamento dei dati applicativi.
Nacque quindi il movimento NOSQL:

Queste slide sono tratte dall'evento live, se siete interessati è disponibile anche la registrazione.


NoSQL & ASP.NET just married!

Il vecchio schema a tre livelli non esiste più. Il database relazionale non riesce più a soddisfare le richieste di applicazioni sempre più esigenti in termini di performance e ricchezza del dato.
Ad oggi le applicazioni enterprise utilizzano tre classi di database, al database relazionale per l'OLTP si è aggiunto il data warehouse per operazioni di analisi del dato e reportistica.
A mettere in discussione la supremazia del database relazionale nel campo dei dati "appena sfornati" ci ha pensato il movimento NoSQL, che propone un modo diverso di memorizzare e consumare i dati applicativi.

nosql
fonte: http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html

Perché NoSQL: un caso pratico

Le interrogazioni che prevedono dati presi da più tabelle sono le operazioni nelle quali il relazionale viene messo a dura prova, indici, viste e denormalizzazioni varie sono rimedi poco efficaci se la nostra applicazione effettua un numero elevato di richieste. In questo caso viene spontaneo pensare ad un sistema di cache e in questo campo il migliore è memcached.

Nel prossimo post vedremo come configurare memcached per velocizzare sensibilmente le nostre applicazioni ASP.NET.

continua...


Come eseguire una stored procedure con Entity Framework 4.0

Ecco come chiamare una stored procedure con Entity Framework 4.0, il codice è preso dalla presentazione fatta all'ultimo evento di 1nn0va:

// Chiama la stored usp_Authenticate passando username e password
var db = new BlogEntities();
var user = db.ExecuteStoreQuery("exec usp_Authenticate {0},{1}",
           username, password);

Modificare lo schema di una tabella in SQL

Per chi ha un sito in hosting su Aruba conosce bene la necessità di dover specificare come schema degli oggetti del database il nome assegnato dal provider, che poi è lo stesso del db. In questi giorni mi sono imbattuto in questa problematica dovendo aggiornare questo blog all'ultima versione di BlogEngine.NET, da qui la necessità di cambiare lo schema predefinito dbo con quello fornito da Aruba. Ecco come farlo con una query SQL:

ALTER SCHEMA MSSql0001 TRANSFER dbo.be_Users

T-SQL: assegnarsi un ruolo con la stored procedure sp_addrolemember

La stored procedure sp_addrolemember viene utilizzata in SQLServer 2005 per aggiunge un utente del database, un ruolo del database, un account di accesso di Windows o un gruppo di Windows ad un ruolo di database per il database aperto nel contesto corrente.
Peccato che non esista un controllo per impedire al chiamante di eseguire la procedura su se stesso. Per evitare questo spiacevole inconveniente è necessario indicare a SQLServer di considerare attendibile il database in oggetto attraverso il seguente script sql:

ALTER DATABASE dbname SET TRUSTWORTHY ON

Quando il database è impostato su TRUSTWORTHY ON non è però possibile eseguire l'impersonate di un altro utente, se ne abbiamo la necessità dobbiamo prima impostare TRUSTWORTHY ad OFF come nell'esempio seguente:

EXECUTE AS LOGIN = 'login1';
GO
--Set TRUSTWORTHY OFF
ALTER DATABASE dbname SET TRUSTWORTHY OFF
GO
EXECUTE AS USER = 'user2';
--Execution context set to user2
GO
--Set TRUSTWORTHY ON
ALTER DATABASE dbname SET TRUSTWORTHY ON
--Reset the execution context to the previous context
REVERT;
GO

Nota: Per impostare questa opzione, è necessario essere un membro del ruolo sysadmin.


T-SQL: gestire permessi a livello di colonna

Nella gestione della sicurezza di un database può essere necessario in alcuni casi arrivare a definire dei permessi a livello di colonna.
Nell'esempio di codice Transact SQL sottostante vediamo come in SQL Server possiamo negare all'utente di tipo studente la modifica della colonna Matricola all'interno della tabella dbo.Studenti del database Universita:

USE Universita
GO
DENY UPDATE ( Matricola ) ON OBJECT::dbo.Studenti TO studente

Database: tabelle temporanee in PL/SQL

Può essere di grande aiuto in alcune operazioni SQL avere a disposizione tabelle intermedie su cui salvare dei risultati per una successiva elaborazione. Quando lavoriamo con database Oracle abbiamo a diposizione due soluzioni.
Possiamo creare delle tabelle temporanee globali direttamente con un CREATE TABLE, oppure ricorrere a variabili di tipo tabella. La prima soluzione è utile nel caso di manipolazione di grandi quantità di dati e ci permette di decidere se lasciare o meno i dati in tabella conclusa la sessione. Vediamo la sintassi PL/SQL:

CREATE GLOBAL TEMPORARY TABLE tempPhoneBookTable
(
   name VARCHAR2(40),
   surname VARCHAR2(60),
   phoneNumber VARCHAR2(15)
) ON COMMIT PRESERVE ROWS; --preserve data after commit

Per approfondire l'argomento sulle tabelle temporanee globali vi consiglio l'ottimo articolo di Don Burleson su come utilizzare le tabelle temporanee per aumentare le performance di una query.

La seconda soluzione consente di definire variabili di tipo tabella direttamente all'interno dello statement o della procedura e di utilizzare metodi specifici per manipolare i dati della collezione. In Oracle le variabili di tipo tabella possono essere paragonate a tabelle di database ad una sola colonna. Nella dichiarazione della variabile devo quindi indicare il tipo di dato da memorizzare. In alcuni casi, come nell'esempio seguente, avrò bisogno di più colonne, devo ricorrere quindi all'utilizzo dei record:

SET serveroutput ON
DECLARE
--define a record
TYPE contact IS RECORD (
    name VARCHAR2(40),
    surname VARCHAR2(60),
    phoneNumber VARCHAR2(15)
    );
--define a table composed of records
TYPE phoneBook IS TABLE OF contact
   INDEX BY BINARY_INTEGER;

--declare a TABLE variable of this type
myPhoneBook phoneBook;
counter INTEGER :=1;

BEGIN
    myPhoneBook(1).name := 'Manuel';
    myPhoneBook(1).surname := 'Scapolan';
    myPhoneBook(1).phoneNumber := '555-5555';

    myPhoneBook(2).name := 'Mario';
    myPhoneBook(2).surname := 'Rossi';
    myPhoneBook(2).phoneNumber := '666-66666';

    WHILE myPhoneBook.EXISTS(counter) LOOP
    dbms_output.put_line(myPhoneBook(counter).surname || ' ' 
        || myPhoneBook(counter).name || ' tel. ' 
        || myPhoneBook(counter).phoneNumber);
    counter := counter+1;
    END LOOP;
END;
/