--- In firebird-support@yahoogroups.com, "martinthrelly"
<martinthrelly@...> wrote:

>
> hi there. im building a .NET application with a Firebird 1.5 backend.

This early in the design, you should consider building it against a FB
2 backend. If you wanted to keep 1.5 compatibility, just don't use the
new features, but the syntax in FB 2 is more strict in places.

> the application in question needs to persist security configurations
> on a per role basis. these security settings come in many different
> flavours. e.g. access rights to modules, visibility/enabled status of
> individual controls, filtering of data based on permission levels, etc.
>
> ive thought about creating Tables to store this information. i could
> pull it off, but the security configs are so varied in nature that i
> thought a document format would be a much more suitable vessel.
>
> the problem with XML is that i will still want to store it in the
> database for security reasons. i am considering keeping this nice and
> simple. i could store my XML data inside a BLOB field. then i could
> simply load my security based XML when the application is first
> launched then just keep it in memory.
>
> my only concern is about the robustness, performance and general good
> practice aspect of storing XML in BLOBS like this. im thinking should
> be fine. just wanting to double check with you guys. thanks.
>

BLOBs are simply a way of telling Firebird to just store a piece of
data without attributing any meaning to it. When you store a field as
an integer, you can do comparisons, build indices and get ordered sets
of information. With a BLOB, you can not ask for this.

With a field you can update one of your settings without having to
update all of them. This may be significant if your XML file is
relatively huge.

There is a subtype of text which will allow implicit conversions from
string literals, but it is otherwise pretty limited.

BLOBs require a second round trip to collect the data, again depending
on the speed of the network and the frequency of application loading
may be significant.

In terms of data visibility settings, using a normal table field
allows you to simply join to it, or refer to it inside a stored
procedure. Relying on the XML logic, you would have to either modify
your SQL statement to take the setting into account, or pull back
unnecessary data and filter it then. Again, depending on the frequency
of this sort of thing happenning and the server resources may tell
whether it is a big problem or not.

Adam