Page 1 of 1
Collection options
Posted: Fri Aug 07, 2009 1:10 pm
by ConvertFromOldNGs
by Anonymous >> Mon, 17 Sep 2007 15:05:42 GMT
I'm in the process of creating a new collection and wondered what the considerations are with regards to whether you should map exclusive instances to its own map file or that of the owner?
Re: Collection options
Posted: Fri Aug 07, 2009 1:10 pm
by ConvertFromOldNGs
by
dcooper@jade.co.nz >> Mon, 17 Sep 2007 21:28:49 GMT
If you expect the collecton to become quite large, it can be beneficial to map it to its own file to separate instances of the collection from other objects in the owner's file. This can help to improve reorg performance if you make changes to your system in the future by isolating the objects that need to be processed. For example, if you change the collection structure in the future, only the collection's map file needs to be processed (ignoring any inverse maintenance). And likewise any changes to objects in the owner's file will only require that file to be processed (which has none of the collection data in it).
Dean.
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by Dan >> Thu, 20 Sep 2007 12:34:03 GMT
Are there any runtime performance gains to be made? Does it matter to Jade if they are in seperate map files but often accessed in close vicinity in code?
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by Dan >> Thu, 20 Sep 2007 12:34:45 GMT
Are there any runtime performance gains to be made? Does it matter to Jade if they are in seperate map files but often accessed in close vicinity in code?
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by Anonymous >> Thu, 20 Sep 2007 12:38:37 GMT
Are there any performances gains at runtime with regards these options? That is, if the owner of the collection and the collection are often accessed as part of one business process would it impact on performance in anyway if they were in seperate or the same map files?
Thanks,
D.
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by Anonymous >> Thu, 20 Sep 2007 12:39:03 GMT
Are there any performances gains at runtime with regards these options? That is, if the owner of the collection and the collection are often accessed as part of one business process would it impact on performance in anyway if they were in seperate or the same map files?
Thanks,
D.
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by Anonymous >> Thu, 20 Sep 2007 12:44:24 GMT
Are there any performances gains at runtime with regards these options? That is, if the owner of the collection and the collection are often accessed as part of one business process would it impact on performance in anyway if they were in seperate or the same map files?
Thanks,
D.
Re: Collection options
Posted: Fri Aug 07, 2009 1:11 pm
by ConvertFromOldNGs
by cnwjhp1 >> Thu, 20 Sep 2007 21:39:02 GMT
Short answer: it doesn't usually make much difference to runtime. What does matter is that you keep already-accessed data in Windows file-system cache (by having enough ram), and that the data is stored in a small area of the disk rather than scattered all across it. Assuming you are using NTFS, there isn't much control of that. Even in the same file, NTFS may scatter it around. Defragging is more important than which map file you store it in. You can help prevent NTFS fragmentation by setting these .ini file options to something reasonable:
[PersistentDb]
DefInitialFileSize=100K
DefFileGrowthIncrement=1M
Dean mentioned the main reason to use separate map files - to help reduce reorg times, and make the files more manageable. One system I am involved with has 5 collections around 10gb each, and the class is 22gb, so those were all split out separately, but only for reorg and operational reasons.