Some thought on a semi-separation model

[harryk]

Having thought of data separation, and noticing it is a hot topic now, just a thought for what it's worth.

Data separation is a good thing, but it can be complex. It solves problems (data import after upgrading for example) but creates other problems to solve, too.

My thought is, that if a database is relatively simple, and not too huge, you might think of a semi-solution. That is, that the main operations are executed on the main file (and perhaps some related files), just as you were used to without data separation. Extra though, is the built in option, to scripted export and import of data from the main file to a backup-data file (related of course), fully controlled through scripts. When update is needed of the main file, the data in it must be backed up to the data-file, before it is replaced. The new main interface file can be delivered/installed empty, scripts and control flags take care of the 'refill' of the main file with the contents of the related data file.

The extra work of this scenario is scripting (field by field) the in- and export of the data. You could script it in a way that modifications are noticed and that on startup and/or closing the file the data-file is kept up to date. Extra benefit, some kind of backup.

Just a thought.

Harryk

[DLS]

I am fairly deep into a project now that started out with three files. Data, GUI and BR. I dropped the BR file because I just could not see any advantages and the extra work and complexity did not seem worth it. Also, does anyone have any feedback on performance with the BR file? My thought is that if all calcs (derived data fields) reside in the BR then they all must be unstored because they involve relationships. When it comes to performing finds, summarizing, etc. for reports on a large file on unstored calcs things really slow down.

I now have Data and GUI files and am seriously thinking about scrapping the GUI and going to one file. Even though the main relationship graph is in the GUI there are still relationships that need to be created in the Data file resulting in duplicate relationships/work. With two or three files and all the relationships, etc. it adds a lot of complexity which in turn can lead to more bugs and debugging.

Even implementing your export/import solution would be less complex in a lot of ways.

I am still not totally sold on the total separation model. Maybe when I put together my canned solutions I may see things differently but for now for me it creates a lot more work with not many advantages that I can see.

One last thought. I am still messing with this but initially there are some issues with two or three files when it comes to instant web publishing, logging in, opening files, etc.

[pezagency]

Even though the main relationship graph is in the GUI there are still relationships that need to be created in the Data file resulting in duplicate relationships/work.

If you're creating relationships in the data file then you're not creating data objects. Anything that can't become a data object is business logic and belongs in the business logic layer, linking to the data object, as far as I understand.

I am still not totally sold on the total separation model. Maybe when I put together my canned solutions I may see things differently but for now for me it creates a lot more work with not many advantages that I can see.

The advantages aren't obvious if there isn't any true separation. Business logic is defined by the business that uses the data--the same data used by different businesses, for example. For developers, this means modular, flexible systems.

I've used this model with PHP, it's tricky, but once you get the hang of it, it's really great.

Right now I'm wondering if layers can be built in one file--in other words, just building the layers in one Filemaker file.

And also, since I've just started using FM7, I'm having trouble understanding how to duplicate keys upon record creation, for example.

[pezagency]

Even though the main relationship graph is in the GUI there are still relationships that need to be created in the Data file resulting in duplicate relationships/work.

If you're creating relationships in the data file then you're not creating data objects. Anything that can't become a data object is business logic and belongs in the business logic layer, linking to the data object, as far as I understand.

I am still not totally sold on the total separation model. Maybe when I put together my canned solutions I may see things differently but for now for me it creates a lot more work with not many advantages that I can see.

The advantages aren't obvious if there isn't any true separation. Business logic is defined by the business that uses the data--the same data used by different businesses, for example. For developers, this means modular, flexible systems.

I've used this model with PHP, it's tricky, but once you get the hang of it, it's really great.

Right now I'm wondering if layers can be built in one file--in other words, just building the layers in one Filemaker file.

And also, since I've just started using FM7, I'm having trouble understanding how to duplicate keys upon record creation, for example.

[pezagency]

Even though the main relationship graph is in the GUI there are still relationships that need to be created in the Data file resulting in duplicate relationships/work.

If you're creating relationships in the data file then you're not creating data objects. Anything that can't become a data object is business logic and belongs in the business logic layer, linking to the data object, as far as I understand.

I am still not totally sold on the total separation model. Maybe when I put together my canned solutions I may see things differently but for now for me it creates a lot more work with not many advantages that I can see.

The advantages aren't obvious if there isn't any true separation. Business logic is defined by the business that uses the data--the same data used by different businesses, for example. For developers, this means modular, flexible systems.

I've used this model with PHP, it's tricky, but once you get the hang of it, it's really great.

Right now I'm wondering if layers can be built in one file--in other words, just building the layers in one Filemaker file.

And also, since I've just started using FM7, I'm having trouble understanding how to duplicate keys upon record creation, for example.