Great, great presentation. Some real nuggets here (nuggets within nuggets): 16:55 FK's belong to the database (see also 32:30) Lookout for Kent's approach to naming with prefixes. 19:41 naming: notice the FK_ prefix on Kent's foreign keys which makes reading your code and queries much easier down the road. 20:30 more on naming 27:30 StoredProcs allow ORDER BY vs Views 28:35 Retrieving indexes from SQL server 31:30 naming of indexes that you create 36:30 Tables: Entity vs Transaction 36:55 Kent's approach to Transaction Tables (very important for Audit)
thank you, @gregoryregan3000. Kent made some very good points! I'm looking forward to his presentation on Friday (Thursday for me) on migrating Access to SQL Server.
@@LearnAccessByCrystal your relationships tool is great. I wish I had this when I started out with Access many years ago. Thanks for the peek under the Access covers.
This is so interesting, I’m only half way through maybe this will come up but I’m so surprised about not using cascade delete, I generally always have that on my Main to Detail tables, so if the Parent is deleted their children will be also. Also just realised that with my mapping tables, I probably could have had my unique identifier as the map, so when that changes (it sometimes does) it will automatically update all the references to that map, whereas I go through and update them all to the new mapping name I’m using.
thanks, Tezza. Cascade Delete depends on the business rules you decide. Most of the time, I would rather not let it happen automatically as it could be dangerous to lose child records that maybe just need to hook to something else. Or at least make an informed decision -- sometimes users don't think about all the related records that could be lost too. On Cascade Update ...if your mapping is lots and lots of points, it's more efficient to use an AutoNumber primary key with Long Integer foreign key. Then your parent table could have one field that gives a name to the primary key. If your mapping is as Kent is doing with table names, where he wants to be open the fields table without joining in the parent, it's a good consideration.
Great
thank you!
Great, great presentation.
Some real nuggets here (nuggets within nuggets):
16:55 FK's belong to the database (see also 32:30)
Lookout for Kent's approach to naming with prefixes.
19:41 naming: notice the FK_ prefix on Kent's foreign keys which makes reading your code and queries much easier down the road.
20:30 more on naming
27:30 StoredProcs allow ORDER BY vs Views
28:35 Retrieving indexes from SQL server
31:30 naming of indexes that you create
36:30 Tables: Entity vs Transaction
36:55 Kent's approach to Transaction Tables (very important for Audit)
thank you, @gregoryregan3000. Kent made some very good points! I'm looking forward to his presentation on Friday (Thursday for me) on migrating Access to SQL Server.
@@LearnAccessByCrystal your relationships tool is great. I wish I had this when I started out with Access many years ago. Thanks for the peek under the Access covers.
This is so interesting, I’m only half way through maybe this will come up but I’m so surprised about not using cascade delete, I generally always have that on my Main to Detail tables, so if the Parent is deleted their children will be also.
Also just realised that with my mapping tables, I probably could have had my unique identifier as the map, so when that changes (it sometimes does) it will automatically update all the references to that map, whereas I go through and update them all to the new mapping name I’m using.
thanks, Tezza. Cascade Delete depends on the business rules you decide. Most of the time, I would rather not let it happen automatically as it could be dangerous to lose child records that maybe just need to hook to something else. Or at least make an informed decision -- sometimes users don't think about all the related records that could be lost too.
On Cascade Update ...if your mapping is lots and lots of points, it's more efficient to use an AutoNumber primary key with Long Integer foreign key. Then your parent table could have one field that gives a name to the primary key. If your mapping is as Kent is doing with table names, where he wants to be open the fields table without joining in the parent, it's a good consideration.