Received: by 10.68.241.162 with SMTP id wj2mr5497551pbc.2.1340644563419;
        Mon, 25 Jun 2012 10:16:03 -0700 (PDT)
X-BeenThere: dddcqrs@googlegroups.com
Received: by 10.68.240.165 with SMTP id wb5ls14834745pbc.1.gmail; Mon, 25 Jun
 2012 10:16:00 -0700 (PDT)
Received: by 10.68.227.67 with SMTP id ry3mr10078958pbc.8.1340644560813;
        Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
Received: by 10.68.227.67 with SMTP id ry3mr10078957pbc.8.1340644560805;
        Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
Return-Path: <joao.paul.braga...@gmail.com>
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44])
        by gmr-mx.google.com with ESMTPS id tf10si3334976pbc.0.2012.06.25.10.16.00
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of joao.paul.braga...@gmail.com designates 209.85.160.44 as permitted sender) client-ip=209.85.160.44;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of joao.paul.braga...@gmail.com designates 209.85.160.44 as permitted sender) smtp.mail=joao.paul.braga...@gmail.com; dkim=pass header...@gmail.com
Received: by pbcwy7 with SMTP id wy7so8831426pbc.17
        for <dddcqrs@googlegroups.com>; Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:reply-to:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        bh=F6Gjb8xYoaqzd8JhktTF+mWBsm/N3+gctn2YOsXjMRM=;
        b=wzegH250uuFGy0k1AtsX53pHJpMiPnfLpmHqvn5qS/BIdYXhSrfecZqMWYW2BmmJOh
         /1PBuGvdzASJJffoJTFE6plKY1ph1/YApgh1suaaRbotujiiRIBJK5rploBcwLoQj9zT
         W52fJrW5eiZ26DnqhhDit1jMZz3fV5dD8/QRnmBINJNeTLcFTpxF1z1dLr+5+WF9NwN5
         zMsHxPwClv4N56TZdoZezU8Fs4sI+Fj+8Kv0hjA5L/QQx7Oad1PxGF/xHOlIX4CL6nLc
         TE23GU6eBlwG3mEQbmpvE5K0mu1mUCezB4mCk2Ft9Dwtlw/kJAzj55sJoRlG9SliRbxa
         I/nw==
MIME-Version: 1.0
Received: by 10.68.236.102 with SMTP id ut6mr41996831pbc.113.1340644560438;
 Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
Reply-To: joao.p...@braganca.name
Sender: joao.paul.braga...@gmail.com
Received: by 10.68.224.36 with HTTP; Mon, 25 Jun 2012 10:16:00 -0700 (PDT)
In-Reply-To: <7820f512-e42d-49dd-ad16-29036936c70f@googlegroups.com>
References: <7820f512-e42d-49dd-ad16-29036936c70f@googlegroups.com>
Date: Mon, 25 Jun 2012 10:16:00 -0700
Message-ID: <CACxseT7CtSqFKbow3u=zue2tE0JRq67wON4RHmJvPoCc9a0...@mail.gmail.com>
Subject: Re: [DDD/CQRS] SQL Server Read Store Performance when using Guids for
 Aggregate ID values
From: =?ISO-8859-1?Q?Jo=E3o_Bragan=E7a?= <joao.p...@braganca.name>
To: dddcqrs@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1

Since you are already using, Raven, why not use it for the read model
too? What you could do is let Raven generate its own id using hi lo.
Use the index replication bundle to get it into sql server.

On Mon, Jun 25, 2012 at 9:48 AM, @nbarnwell <mail...@neilbarnwell.co.uk> wrote:
> I've just submitted the first patch for a greenfield DDD/CQRS/ES app to our
> DBA team and they've come back with (amongst other things) one very specific
> point.
>
> I've chosen in my Application Services to generate the AggregateID values
> for newly-created aggregates as Guids (I'm using .NET so quite literally
> Guid.NewGuid()).
>
> As per the typical design, the Aggregates generate Events, which are shipped
> asynchronously to some apps responsible for updating various read stores.
> One is Neo4j, one is SQL Server. For the SQL Server read store, I have a
> table similar to this:
>
> create table Thing (
> Id uniqueidentifier not null,
> [Version] int not null,
> Name varchar(255) not null,
> constraint PK_Trip primary key (Id)
> )
> GO
>
> The usual issues with Guids is being suggested (performance, clustered index
> fragmentation etc). Given however that this isn't an OLTP db (my event store
> is RavenDB using my Regalo CQRS library), do I have options here? I'm
> thinking things like having a different clustering key value (that's
> incremental for clustering purposes though I actually ignore it) to the PK
> (my application-generated aggregate ID).
>
> Many thanks in advance.
>
> Neil.