Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 20 of 43 total
Thread Questions on Catalogs
Fri, Oct 24 2008 3:56 PMPermanent Link

David
On 10/24/08 3:36 PM, in article
F997C38A-23F8-4083-B8F9-881A7120E06D@news.elevatesoft.com, "Tim Young
[Elevate Software]" <timyoung@elevatesoft.com> wrote:


> No, the catalog does not store any "data" such as autoinc values.  Those are
> all stored in the table.

> You hate replicated code, but you don't have a problem with replicated
> metadata and structural information that could lead to all sorts of issues ?
> I'll take the replicated code. Smiley

I may be misunderstanding the discussion, but I think the concept boils down
to "normalization" of the database itself.  Store the info about the DB in
one place only.  Storing the DB's info in more than one place is just like
having two clocks in a room.  Only one of them will ever be correct.

If I'm way off, just ignore me.  Smile
Fri, Oct 24 2008 7:02 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

David,

<< I may be misunderstanding the discussion, but I think the concept boils
down to "normalization" of the database itself.  Store the info about the DB
in one place only.  Storing the DB's info in more than one place is just
like having two clocks in a room.  Only one of them will ever be correct. >>

True, but there's a difference between the *actual* database metadata, and
the information *about* the database metadata that the application contains.
The two will never be one and the same.  One is used to validate against the
other to make sure that the application/server is accessing a database with
a makeup and structure that is applicable to that application/server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Oct 24 2008 7:12 PMPermanent Link

Sean
Tim,

Just curious. If the table files only contain data and the catalog file
is deleted or corrupted does that make the entire database unrecoverable
or does EDB have a way to repair/construct a catalog from the remaining
table files?

Also, did you change your mind on the single-file database format for
the enterprise server product?

Thanks,

Sean

> EDB does not work that way.  The catalog is not just a data dictionary that
> stores the structure of the tables, and then the table files *also* have
> their own structure that can be compared to the data dictionary.  In EDB,
> *only* the catalog has the metadata about a table.  The table files *only*
> contain the data, nothing else.  Therefore, it is imperative that EDB make
> sure that the table file being accessed matches the catalog via its version
> number.  If it doesn't, then EDB must prevent access because otherwise it
> would cause all sorts of AVs and errors.
>
Sat, Oct 25 2008 3:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>What you're missing is that you're talking about an exhaustive metadata
>resolution process *every time a database or table is opened*. It would
>have to be that way if we went with a design like what Stefano is
>recommending. Furthermore, it doesn't even begin to deal with how to
>reconcile missing RI structural information, and how easy it would be to
>break such an RI design. That's why I'm saying that you're not thinking
>this through.

I think we are heading down different paths. What I was talking about is multiple identical databases apart from the data so "reconcile missing RI structural information" is the same as for any one database.

>You hate replicated code, but you don't have a problem with replicated
>metadata and structural information that could lead to all sorts of issues ?
>I'll take the replicated code. Smiley

Tim that was/is the whole point I don't want to replicate it - I just want to use it in multiple places simultaneously. Currently if I have three companies set up I have three different catalogs - that's replication.

Still as I said in my original post "I don't know if this is even possible (almost certainly not) but I really like the idea." Note the "almost certainly not"

Roy Lambert [Team Elevate]
Sat, Oct 25 2008 3:30 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Sean

>Just curious. If the table files only contain data and the catalog file
>is deleted or corrupted does that make the entire database unrecoverable
>or does EDB have a way to repair/construct a catalog from the remaining
>table files?

If you loose the catalog, and have no backup the best you can do is recreate the structure manually and if the version numbers are incompatible ask Tim for some help.

Roy Lambert [Team Elevate]
Mon, Oct 27 2008 1:27 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Sean,

<< Just curious. If the table files only contain data and the catalog file
is deleted or corrupted does that make the entire database unrecoverable or
does EDB have a way to repair/construct a catalog from the remaining table
files? >>

See Roy's response.  It would take some serious manual work to get the
database back, so the best solution is to a) not delete the catalog file and
b) make regular backups.  Also, any time the catalog file is updated, it is
backed up in a fail-safe manner, so there really isn't any way for the
catalog to become corrupted.

<< Also, did you change your mind on the single-file database format for the
enterprise server product? >>

No.  This discussion is regarding the current ElevateDB product.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Oct 27 2008 1:33 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I think we are heading down different paths. What I was talking about is
multiple identical databases apart from the data so "reconcile missing RI
structural information" is the same as for any one database. >>

Okay, now you're definitely talking about something completely unrelated.
Stefano was talking about storing the metadata in the table files
themselves, ala DBISAM, and that was what I was responding to.

<< Tim that was/is the whole point I don't want to replicate it - I just
want to use it in multiple places simultaneously. Currently if I have three
companies set up I have three different catalogs - that's replication. >>

My understanding of what you said was that you're saying that you don't want
to have to store the code for creating the database in your application.  If
you're saying that you want one catalog to control more than one database,
then, yes, something like that could, theoretically, be done.  However, I
probably won't implement such a feature due to the amount of work involved
for very little payback.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Oct 28 2008 2:21 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>Okay, now you're definitely talking about something completely unrelated.
>Stefano was talking about storing the metadata in the table files
>themselves, ala DBISAM, and that was what I was responding to.

In that case I misunderstood Stefano's post

>My understanding of what you said was that you're saying that you don't want
>to have to store the code for creating the database in your application.

I'm happy enough to do that (or in an encrypted external text file) after all as Bluebottle said "everybody's got to be somewhere"

>If
>you're saying that you want one catalog to control more than one database,
>then, yes, something like that could, theoretically, be done.

Yup that's what I'd really like to see.

>However, I
>probably won't implement such a feature due to the amount of work involved
>for very little payback.

Expresses total lack of surprise <vbg>

Roy Lambert
Tue, Oct 28 2008 12:51 PMPermanent Link

"Stefano Monterisi"
Tim,






>
> Okay, now you're definitely talking about something completely unrelated.
> Stefano was talking about storing the metadata in the table files
> themselves, ala DBISAM, and that was what I was responding to.
>
No, Tim,

>  If  you're saying that you want one catalog to control more than one
> database, then, yes, something like that could, theoretically, be done.
> However, I probably won't implement such a feature due to the amount of
> work involved for very little payback.

Yes, Tim. This is that I want (sorry,...I like) ; One catalog that control
more than one database;
So all databases that are related to Catalog A, must have the same structure
and logic of A;
All databases that are related to Catalog B, must have the same structure
and logic of B;
So, for ex., I can have a catalog, named (yes, NAMED) DBCatalogBasic that
control one database that contains basic or common tables (companies,
countries, vats, etc.); The database property "CatalogName" must be set for
relate the two entites;
So I can have a catalog, named DBCatalogLedgers thaat control ALL Ledger
databases (one folder foreach company)  because they (must) have the same
structure;
This way I use 2 catalog files for 100-200 databases (plus the basic one)
and I can also use another new (named) catalog if I need a particular
release of a databases;

Catalog Basic - Database Basic
Catalog Ledger - Database Ledger 01,Database Ledger 02,  03,...100, etc.

Another plus, If I need to collate data from several PC, I can name uniquely
catalogs so they cannot be overwritten because I can use catalog001 for
database in PC 001, etc....I have freedom to use catalogs how I like.
The best is if I can distribuite an "updated" catalog and all related
database change automatically the structure on connect (but this involve too
events and cannot be "automagically").

(Sorry for my bad english)

Stefano Monterisi






> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Wed, Oct 29 2008 1:21 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Expresses total lack of surprise <vbg> >>

Well, there are technical issues with it that make it very unattractive
also.  Consider a situation where a table is altered.  This would then
result in N number of alterations across all database directories that are
sharing the same catalog.  Furthermore, how do you know which set of table
files belongs to which database catalog ?  What if there's a catalog file
present in a database directory, but the table files aren't using it ?  What
happens during a restore ?  etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Previous PagePage 2 of 5Next Page
Jump to Page:  1 2 3 4 5
Image