+1-888-365-2779
Try Now
More in this section

Forums / Suggestions / Change to [dbo].[sf_GC_Variables] suggestion

Change to [dbo].[sf_GC_Variables] suggestion

3 posts, 0 answered
  1. Will
    Will avatar
    26 posts
    Registered:
    19 Aug 2008
    24 Nov 2009
    Link to this post
    Since Sitefinity is only using SQL Server you might want to consider using a single sql_variant type column to replace the [ShortText], [DateTimeValue], [IntegerValue], [FloatValue], [GuidValue], and [Boolean] columns.  You only need a nullable sql_variant, a nullable nvarchar(max), and a nullable varbinary(max) column to represent every intrinsic storage type, plus it removes the 250 character limit of ShortText meta data fields increasing it to the normal limit of 4000.  I use this technique in every application that requires a settings table.  Generic methods make the use of sql_variants very easy to work with as well (i.e. GetValue<int>(ContentId, "Count")).
  2. Ivan Dimitrov
    Ivan Dimitrov avatar
    16072 posts
    Registered:
    19 Sep 2016
    24 Nov 2009
    Link to this post
    Hi Bill,

    Sitefinity can uses SQL, MySQL, Oracale, Microsoft Access. Generally we do not recommend making changes to the database. We use Data Layer and Nolics for 3.x versions. From Sitefinity 4.0 we will use OpenAccess. However, for the metakeys you can use LongText, Boolean, Int, FloatingPoint, Guid, DateTime, Binary  types as well.

    Greetings,
    Ivan Dimitrov
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
  3. Will
    Will avatar
    26 posts
    Registered:
    19 Aug 2008
    02 Mar 2010
    Link to this post
    Hey Ivan,

    Sorry it has taken so long for me to reply to this, but I've been exptremely busy and forgot about it.  I understand your reasoning for using Nolics, but it is something that we won't be using.  Normalizing data is one thing, but normalizing the database accessor is something completely different and leads to very poor performance.  We prefer to get the best performance that we can from whichever backend we decide to use, something that a normalized database accessor cannot do.  This is also the reason that we don't use Microsoft's Enterprise Library.

    I've figured out how to use the tables that need to, so I think we're good.

    Thanks,
    Bill
Register for webinar
3 posts, 0 answered