How should I design?

  • Thread starter Thread starter netX
  • Start date Start date
N

netX

I have the following scenario:

I have a books database that contains several tables, with the appropriate
relationships setted up. After I have the db schema, I designed the Book
component, that is constructed to hold information from each table, and also
the Publisher and Author components, that I thought that fits well for
one-to-many, and many-to-many respective.

Now, I'm retrieving and fill a DataSet with all the tables, mentaining the
constraints, and everything's just fine. My problem is that, now every Book
has a collection of Author(s), and when I choose to modify, say ... a
specific author's web address, I wanted that this change to reflect on every
author in every collection of every book that is written by this author.
But, I am constructing the Books when my app is loading, and therefore,
every book gets its own authors collection, so ... the question is ... am I
missing out a good design pattern, or ... do you know any other design
principle that would work on exactely what I expect?

I hope someone can help me to get this out.

Thanks in advance!
 
Hi Netx,

This will be a matter of preference, but I think that you should not collect
more data from a database that you need.

You have authors
You have publishers
You have books (and there are books with two authors to make it a little bit
more difficult).

I think that I would make tables in my database for that like this
Authors (information about the author)
Publishers (information about the publisher)
Book/author collection (reference to find the book with for every
author/book an entree)
Books (information about the book from which one the publisher).

I think that I can find with that what I want.
(And I would not earlier read it than necessary, the pattern you take now
will take only a lot of startup time and in a multiuser environment more
concurency errors).

But just my thought,


Cor
 
Hello Cor,

Thanks for your reply!

First of all, I think you got me wrong. In fact the design of the DB is
already established. And it's much of the same as you proposed, like, the
Books table, the Authors table, and a third table for a many-to-many
relationship between the 2 tables. The problem is not with the design of the
database, it's the design of my app's logic.

Here, I'll try to be more specific.

1) It's a windows app, not a web one.
2) What I need to do is, retrieve all the data from all the tables in my
database, and store it into a DataSet. (Done)
3) Now, based on some criterias (books written by a specific author, or
publisher, or after a given date, or containing some words in the title,
etc.) I need to show the results to the user. The user can also edit a
specific book's informations, and save that back to the database.

Usualy this would be easier if, form all the tables I join the info. into a
single table, but ... here I loose the design of the DB. What I'm doing
right now is ... I am retrieving all the info at runtime, traverse all of it
and create the Book components. But, then, when let's say, someone modifies
the web addres of an author, this change will not be seen in other book,
until the next time the app is opened again, and, just to go through a
search into all the books and check which has this as an author and which
not, doesn't seem to me that logic.

I hope I made things more clear now, and hope I can get a good direction
into this.

Thanks!
 
Hi NetX,

That was why I wrote this

(And I would not earlier read it than necessary, the pattern you take now
will take only a lot of startup time and in a multiuser environment more
concurency errors).

From the recordset time people started to take as much in memory as posible,
it was so nice fast for the user. The recordset is a connected approach.

The dataset is a disconnected approach, that means that there is no
reflection to the database.
You can choose to update everytime your dataset in the computer, but I see
no benefit from it.

I think that taking a partial part in the computer (only the search
information) and than take the real information when needed is a better
approach. (You choose a book and than all the information from the authors
from the book and the bookinformation itself is readed in a seperated
dataset). Of course you still have everytime to check on new, delete and
updated books and authors to update your search information datasets (or
read that completly new).

Than are you everytime reading the last website information of the author by
instance (and only from that author).

But this is an approach I like at the moment, there will be a lot of others
who can say the oposite from what I say.

Cor
 
Back
Top