In memory datu bāzes ir viens no visinteresantākajiem SQL 2014 jaunumiem. Lai šos piemērus pamēģinātu, protams, vajag SQL 2014 CTP2 (kad iznāks gala versija- šobrīd vēl neviens nezin vai nesaka).
Lai nu kā, mēģinot piemērus, neaizmirstiet "SET NOCOUNT ON". Demonstrācijā miljons rindu ievietošanas lielāko daļu laika patērēja tieši ziņojuma "1 row affected" izvadīšana.
set nocount on; -- bez šīs rindas: 00:02:09, ar šo rindu 00:00:49
declare @start datetime = getdate()
declare @i int = 0
begin tran
while (@i < 1000000)
begin
insert Test1 values (@i, 'Product ' + cast(@i as char(6)), 10) -- 22
insert Test2 values (@i, 'Product ' + cast(@i as char(6)), 10) -- 5
insert Test3 values (@i, 'Product ' + cast(@i as char(6)), 10) -- 7
insert Test4 values (@i, 'Product ' + cast(@i as char(6)), 10) -- 4
insert Test5 values (@i, 'Product ' + cast(@i as char(6)), 10) --
set @i += 1
end
commit
select DATEDIFF(ms, @start, getdate())
Microsoft SQL Server vienmēr ir bijis pamatīga bremze gan ātruma ziņā gan funkcionalitātē. Visi normālie datubāžu serveri uz stabīlajām *NIX platformām jau daudzus gadus atbalsta tādas lietas. PostgreSQL servera vēstkopā var 2010tajā gadā viegli atrast diskusijas, kur lietotāji apmainās ar daudzu gadu pieredzi in-memory PostreSQL datubāžu optimizācijā.
AtbildētDzēstMicrosoft atpaliek no IT industrijas par dekādēm un vēl joprojām ar to lepojas.
Izklausās ļoti tendenciozi.
DzēstEs neesmu pazīstams ar PostgradeSQL, bet ātrumā googlē atrodams, ka visdrīzāk izpratne par to, kas ir "in-memory" atšķirās (piem., http://stackoverflow.com/questions/407006/need-to-load-the-whole-postgresql-database-into-the-ram).
Personīgi nepiekrītu, ka SQL Server ir pamatīga bremze ātruma ziņā (es varētu piekrist, ka noteikti ir uzdevumi, ar kuriem viens vai otrs tiek labāk galā). Labrāt piedalītos eksperimentā, kur vienu un to pašu uzdevumu risina izmantojot PostgradeSQL un MS SQL Server..
Arī funkcionalitātes ziņā- manuprāt pēdējo gadu laikā tā ir būtiski papildināta un neredzu iemeslu piekrist ka SQL Server atpaliek no citiem. Atkal- ar piebildi, ka noteikti ir situācijas kurās SQL Server nav labākais risinājums (tāpat kā ir tādas, kurās PostgradeSQL nav labākais risinājums).