Anteckningar om databashanterare

Integration

Att ansluta till datakällor utanför databasen.

Support, End Of Life och RDBMS Version

select version()

select @@VERSION
select name, compatibility_level from sys.databases

select * from v$version

Resurser

• http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems#Databases_vs_schemas_.28terminology.29

Datatyper

Detta är inte en total jämförelse. Jag har försökt undvika att ta med förlegade datatyper.

Not.: PostgreSQL och Oracle hanterar också tidszon med WITH TIMEZONE för date/time-typer

Källa: Wikipedia: Comparison of RDBMS

Slumpmässiga rader

Kan låta enkelt men kräver eftertanke för att lyckas.

Depesz:

http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/

Greg Sabino Mullane:

http://people.planetpostgresql.org/greg/index.php?/archives/40-Getting-random-rows-from-a-database-table.html

Josh Berkus:

http://www.powerpostgresql.com/Random_Aggregate

Undra vad Celko har att säga om detta?

Versionshantering av databas-schema

Versionshantering av databas-schemat är en viktig del i utveckling- och underhålls-arbetet av en applikation.

En utvecklare måste alltid kunna plocka ut den senaste koden och testköra den mot en fräsch och opåverkad databas.

En utvecklare måste alltid kunna laborera och ändra databas- schemat utan att behöva oroa sig för att störa sina kollegors arbete.

För att åstadkomma detta bör databas-schemat, grunddata samt eventuell testdata, versionshanteras tillsammans med övrig applikationskod. Varje utvecklare bör också köra mot en egen databas för att vara ostörd samt undvika att störa andras arbete.

Under initial utveckling då databasen är i ständig flux behöver man inte versionshantera schmat så länge man ser till att kod och databas-schema är i synk i kodarkivet.

När förvaltningsarbetet kommer i gång är det av största vikt att utvecklare kan plocka ut en specifik version av koden och utifrån den skapa en databas för felsökning etc.

Ett hyfsat bra sätt att göra detta på är att i kodarkivet ha senaste versionens databas-schema samt ett patch-skript för ändringar. När en ny version släpps bokför man detta i en tabell i databasen samt uppdaterar schema-filer/n i kodarkivet och tömmer patch-skriptet.

Jobbar man på ovan beskrivet vis minskar riskerna för konflikter och förvirring. Felkällor vid släpp av nya versioner minskas, felsökning i redan släppta versioner underlättas och man får en bra grund för att ytterligare förstärka sitt arbete med nattliga byggen och automatisk testning.

Exempel på versionstabell

Nedanstående skript kan användas för att skapa en tabell för versionshantering.

Lägg märke till att skriptet måste anpassas beroende på vilken databashanterare som det ska köras i.

I nuvarande utförande fungerar det på PostgreSQL, Oracle samt Microsoft SQL Server.

DROP TABLE db_version;
CREATE TABLE db_version
(
   id integer default 1 not null unique check(id=1),
   -- version number(18,2) not null, -- oracle
   version      numeric(18,2)   NOT NULL, -- mssql, pgsql
   -- upgraded_on  datetime      NOT NULL, -- mssql
   upgraded_on timestamp not null, -- pgsql, oracle
   -- script varchar2(254) not null -- oracle
   script text not null -- mssql, pgsql
);
COMMIT;

-- Insert one initial row works:
insert into db_version(id, version, upgraded_on, script) values(1, 1.00, current_timestamp, 'Initial creation');

-- Verify:
select * from db_version;

-- Make sure check constraint works:
insert into db_version(id, version, upgraded_on, script) values(2, 2.22, current_timestamp, 'Failing insert');

-- Update is the only operation that should work:
update db_version set version=1.123 where id=1;

-- Delete should be prevented by trigger but that's an exercise for another day
delete from db_version;

Prestanda

CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO
DBCC FREESESSIONCACHE
GO

Pg relies on the OS's disk cache, which it has no way to clear or control.
On Linux, check out the "drop_caches"