Hi Tommaso,
> The database is the right place in order to do data warehouse, reporting and
> so on not a container of all.
Unless it's a relational database, of course.
Just to cite a few examples, ASP.NET session state or the ASP.NET 2.0 provider
infrastructure data such as membership and roles are commonly stored today in
Microsoft Sql Server, a well known RDBMS. This shows that databases aren't
only for data warehousing and reporting.
Session State Modes on MSDN:
http://msdn2.microsoft.com/en-us/library/ms178586.aspx
Configuring ASP.NET 2.0 Application Services to Use SQL Server 2000 / 2005 on
MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/con
figaspnet_sql.asp
> make sense to store binary data in database?
Serialization into Sql Server, for example, provides relational storage for
the binary data, which is otherwise usually controlled by a file-numbering
system outside of the database. This method of relational persistence isn't
enforced by simple database constraints that ensure the integrity of the data,
but instead only by your code - if done correctly. If each file, commonly
graphical images, are to be saved in reference to a primary key in a database
then it makes sense in some circumstances to just store the data in the
database row along with the related data.
Controlling the serialization of an object and storing it in the database is a
flexible alternative to other persistence mechanism and can be used in
WinForms and web apps to persist complex object graphs without having to write
some proprietary xml schema or file-numbering system that introduces the
possibility for more bugs and requires you to author I/O, which databases
handle for you efficiently, behind the scenes.
Xml object graphs could be used instead to provide a more flexible alternative
to binary serialization. Sql Server supports xpath to query the serialized
structure, in place.
Using XPath Queries on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsql/ac_msche
ma_3gab.asp?frame=true

Signature
Dave Sexton
>> hey all,
>>
[quoted text clipped - 7 lines]
> The database is the right place in order to do data warehouse, reporting and
> so on not a container of all.
pirho - 02 Nov 2006 21:20 GMT
Talk about timely...
I'm actually trying to do this with SQL. I'm trying to store business
objects for auditing purposes, so that I don't have to mess around with the
format of various different types, I want to serialize and store the entire
object.
I'm getting a deserialize error from the following code:
Private Shared Function DeHydrateAnObject(ByVal this As Object) As String
Dim UE As New UnicodeEncoding
Dim m As System.IO.MemoryStream = New System.IO.MemoryStream
Dim b As
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter = New
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
b.Serialize(m, this)
Return UE.GetString(m.ToArray)
End Function
Public Shared Function HydrateAnObject(ByVal this As String, ByVal
strType As String) As Object
Dim UE As New UnicodeEncoding
Dim m As System.IO.MemoryStream = New
System.IO.MemoryStream(UE.GetBytes(this))
Dim b As
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter = New
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
'Dim thisType As Type = Type.GetType(strType)
Return CType(b.Deserialize(m), Product)
End Function
For now, it's hard coded as a "Product"
My question is, for SQL 2000, what database type should I use?
The field is NText right now, but I get the following on the deserialize
Binary stream does not contain a valid BinaryHeader, 0 possible causes,
invalid stream or object version change between serialization and
deserialization
Very new to the serialization stuff, so any ideas would be appreciated.
Dave Sexton - 02 Nov 2006 21:40 GMT
Hi,
You will want to use varbinary or image, depending on the size of your
objects. varbinary can go up to 8000 bytes, IIRC. The large character types
text and ntext are not binary, they are text, so unless you're using a
SoapFormatter or XmlSerializer they won't be of much use to you here.
If you could use the added flexibility of searching the object graph from
within the database itself using Sql Server's built-in xml support then using
the text column type and serializing the object with an XmlSerializer might be
a better choice for you.
Just out of curiosity, why did you choose the term "dehydrate" over
"serialize" and "hydrate" over "deserialize"?
IMO, your code will make more sense if you describe the methods for what they
are actually doing using framework idioms such as "serialize" and
"deserialize".

Signature
Dave Sexton
> Talk about timely...
>
[quoted text clipped - 37 lines]
>
> Very new to the serialization stuff, so any ideas would be appreciated.
pirho - 02 Nov 2006 22:12 GMT
Dave,
The DAO code where I work is all stored in one huge class file.
I didn't want any confusion between my serialization code and the .NET
method(s) #1
and #2, I've been using nHibernate on other projects, so the Dehydrate thing
is a little bit burned into my retina at the moment :-)
Thanks for the answer so quick. Helps to know I'm on the right track.
> Hi,
>
[quoted text clipped - 56 lines]
> >
> > Very new to the serialization stuff, so any ideas would be appreciated.