Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 11 to 20 of 43 total |
Questions on Catalogs |
Fri, Oct 24 2008 3:56 PM | Permanent 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. 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. |
Fri, Oct 24 2008 7:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 Page | Page 2 of 5 | Next Page » |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Thursday, April 18, 2024 at 10:42 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |