An Introduction to Database Models
-
I haven't had a lot of experience with OODBMS's so I can't comment from experience, but it seemed that they were mainly built to "simplify" db access for developers. Rather than having the developer have to understand and store data in multiple places (and retrieve it), it's stored in an object structure and more easily retrieved.
They also have different indexing structures. I too am not sold that they really work well, but I have seen some implementations (can't remember them now, think NASDAQ or Chicago BOT did one, and the performance was far above their old system. I'm not sure this says their approach was better or maybe the previous approach was horrible, but it was interesting.
Good overview Frank!
-
First of all, sorry for being that late on my reply. I was voluntarily completely offline last week.
Glad to see I caused some discussion.
Steve, is it possible to automatically subscribe an author to the thread on his article?
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I thought about the serialization thing a little more and figured out a way to handle the situation where notification needs to be sent when changes are made to the database. There are two ways to handle this.
Message Queuing - This is exactly the sort of thing queuing is for. It guarantees that you message gets to all the destinations so you can put a message on the queue and the queue reader for the database change with post the update to the database and the email queue reader will shoot an email to the appropriate recipients.
Email Service - Providing an email service in your business layer would allow you to make the database update and then fire off an email through an email service you create. The queuing option is probably more reliable but may involve a learnign curve.
There are probable other options out there but I want to mention that email is inherently unreliable unless you have a mechanism for ensuring delivery and SQL Server can't do that very well. This does not take into account the reliability of SQL Mail. I have had enormous amounts of trouble with SQL Mail and I highly recommend that it not be used for applications. It is fairly stable if you're just sending alerts from SQL Server and SQL Agent but relying on it for business needs is not a good idea. If you have the capability to monitor the event log, I would not even use SQL Mail at all; just make sure that critical alerts are posting to the Windows Event Log.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
This does not take into account the reliability of SQL Mail. I have had enormous amounts of trouble with SQL Mail and I highly recommend that it not be used for applications. It is fairly stable if you're just sending alerts from SQL Server and SQL Agent but relying on it for business needs is not a good idea.
Ok... now I'm beginning to worry:
Alarm messages filter into a public folder on our Exchange server, and these need to get into SQL somehow.
I was going to write a stored procedure that did the xp_OpenMail, insert into foo from selectunread, xp_CloseMail bit, but if sqlmail's reputation holds true, it sounds like I'm in trouble
Any suggestions?
(I do like your suggestion for using MSMQ for reliable msg delivery and will use it when we get around to the notification part of the project)
-
Where do the alarm messages come from? Would there be a way to dump them to a flat file or something? The .NET framework provides a file/folder listener that can detect changes to a file and provide events to an application or service so the events can be handled.
The main problem I have seen with SQL Mail has been with sending emails. I have never used it to read mail before. The problems tend to occur in MAPI sessions and to get a session to quit, you need to restart the SQL Server services. If your system is on a cluster, I would forget even attempting to use SQL Mail. Microsoft does not support SQL Mail on a cluster due the the MAPI sessions inability to fail over with the SQL Server. I have seen other problems with MAPI on clusters that may or may not be related to clustering itself.
My suggestion is to look at the problem your software is intended to solve from end-to-end and see where you might be able to streamline some things that will make future development faster and more able to provide better service. This might make the overall project timeline shorter even if the current phase goes into overtime.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
Frank, nice to see you back. I've also been gone a couple of weeks (not voluntarily - on the road/busy).
Thank you Frank and to all of you for making interesting forum article reading.
I hope I don't ramble to much here, but I do have some thoughts...
I'm by no means a theoretical database expert, or for that matter cared very much about
the theoretical reasons for databases and how the data model is designed. In my opinion,
the database and DBMS exist for the purpose of recalling information in a form and
accuracy required by the querier. Personnally I've tended to gravitate toward DBMSes that
provide me with a rich programming environment "close" to the data, while providing
the performance required by the application(s). We all know that given enough time, we
could write interfaces to make most all the DB models "look" the same to the end user,
and also the programmer. At this time the relational model, the DBMSes that support
it, seem to provide the best (in most) of the database & programming aspects we all
consider important.
I think we mostly like the relational model because it's the closest thing to the type
of data we deal with most of the time: "Business Data". Since this is the kind of data
where the "money" is, it's had the most effort put towards it. This is why we have ever
evolving and better DBMSes as the computer age matures. I think the way todays computers
are built, and the way business conducts itself, has created the databases & DBMS we see
today.
Here comes the Sci-Fi part...
I agree with Frank on the notion that the future holds exciting new database models to
discover. I've always wondered about the merger of motion pictures (and now with DVD,
random access motion pictures), virtual reality (VR) and databases. Remember the "goal" of
the database: "To recall information". I can imagine a VR interface to database data, such
as Lawnmower Man movie kind of portrayed, where the user navigates to the targeted information
using the basic "human with world" interface(s). Whether it's voice recognition or just plain
old thought that formulates the "query", the end result is that the user recieves the
information requested.
Another slant I have, is the human brain itself. What a wonderful database! All kinds of input
sources, recall methods, fuzzy logic, and even "imagination". Imagination = make new data from
sometimes nothing, WOW! I know your saying, or at least I'm thinking... what about data integrity
and accuracy? The brain fails so often in this respect. Well my answer to that is: some data does
NOT have to be completely accurate. Let me give some examples. Any of us that have tables that
contain street addresses, most of the time do not care if the user typed in "123 Main Street" or
"123 Main Str.". Also, in some high volume DBMS COUNT() may produce inaccurate results. So do we
care about accuracy? Sometimes. The brain seems to figure this out for us pretty good. i.e. It
recalls accurately my wife's birthday (most of the time). Also seems to keep my heart beating
while I sleep, and has done this unfailingly, or at least to my satisfaction for many years.
It can also recall some thing with great accuracy such as anything times zero equals zero. We also
"know" things like a red traffic light means stop etc. These are "learned". Other things our brain
just knows on it's own. So I think data integrity and accuracy are not absolutes, more degrees of
suitability to the task at hand. There are many comparisons to be made between how our brain works
and how users want to use computer databases. I also think that accuracy and reliability can be
build into man-made databases that can overcome "flaws" that natural databases may have in them.
There is another "database" that is extreamly facinating... The DNA molecule and it's chromosomes.
Two "databses", combining to make a new, unique structure, and likely containing more data than
any of us ever deal with.
I know this is biological stuff, but the biological world is the only real place to look, outside
of our own human inventions, for things that are "self changing" or "alive".
I think the relational model will be used for business databases for quite sometime. Other
applications such as medical/scientific and entertainment will most likely use proprietary
database models. Only if they achieve "critical mass" (enough $$$$) would any of them become
mainstream. Relational databases will be used (and stretched) for tasks having little to do
with business data, because it is mainstream, and more resources are available to accomodate
the needs quickly. This my be close-minded on my part, but I think until computers operate
in a very different manner than they do today, the database models available to us will be
pretty much a form of what we using today, just much more advanced perhaps as time goes by.
One thing the relational data model does not do well, or not at all, is "analog" pattern matching.
Example Query: Name the people who are in the same photograph with me within the last year,
who are not relatives....etc. You get the picture (pun intended). Future database models might
handle stuff like this, and might even handle business data better than the relational model
does. Who knows? I think this type of database ability goes beyond "Type" support referenced
by Chris, and requires other/different database models.
Just my $.02
Once you understand the BITs, all the pieces come together
-
Hi Thomas,
surely a little bit late for a reply, but here it goes.
Yes, the human brain is the most powerful database around. Curious how the indexes would look like.
Now as I have read the responses and thought over them for a while I'm glad that I cancelled my idea of writing an article about moving object databases. I think it would only lead to confusion here
...and after all it is not SQL Server related anyway.--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply