This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I'm migrating our application from a legacy DAL to LightSpeed over time. In the process I'm having to add a few new tables to the application. The legacy tables use the IdentityColumn identity method by necessity. I'm thinking of using the LS default method for new tables based on the recommendation in the documentation (regards efficiency) thinking I'll be able to migrate the other tables to the LS default method in future. Is this wise or should I just stick with the IdentityColumn method and worry about migrating later... or not migrating at all due to the complexities? Not sure whether I'm overthinking this so any wise comments would be appreciated. |
|
|
Your plan to use KeyTable for new tables, and stick to IdentityColumn for existing tables, sounds like a very good approach. We would not anticipate any technical complexities from this. The potential complexity arises more from operations: ops staff would need to remember that different tables worked in different ways, and to be aware of how to work safely with the new tables. (For example, in a KeyTable scenario, if ops staff needed to enter new records via SSMS/osql/Toad/SQLPlus/etc as part of maintenance or recovery, they'd need to be careful that the ID wouldn't later be allocated from the KeyTable.) Other than this, your plan seems to minimise risk, which is always a good idea when migrating existing applications! If your ops people are concerned about parallel methods, then don't be too worried about sticking with IdentityColumn even for new tables. You will lose some performance, but unless you're doing a lot of bulk operations, the impact will probably be minor. If you're usually only inserting a few entities per unit of work, you probably won't even notice the difference. If in doubt, try both approaches and measure. As to whether you should plan to migrate the older tables later, I'd suggest that be guided by your experiences with the migrated system. For example, you might decide to tackle it if inserts in the old tables are measured to be a performance bottleneck, or if ops staff or maintenance programmers find the parallel methods confusing. But if it turns out it ain't broke, I'd say don't fix it! |
|
|
Currently doing the same thing and had no problems so far. Lightspeed makes that really easy :) |
|