![]() ![]() OK if the database were accessed from hosts without knowledge of the design. In my simple world, that setting makes the constraints losing most of the purpose. This surprises me and I'm not sure how to handle it. Some cases requires up to 10 levels of an exact order to make a single delete. Which means that you have to play "seek and find" when coding new database queries. ![]() What disturbing me is all constraints configured inside SQLserver with "not cascade". The design looks regular good, mostly mirrored the objects used by the applications. This is usually not a question up for decision, but this database is designed quite different. Doing constraints inside the server is just about making (forcing) same changes twice? ORM tools such Entit圜ontext, Linq2Data, NHibernate are also handle the constraints by themselves, at least you know what tables that need each other. ![]() I won't load a bunch of constrained tables for a simple look-up, which in turn (after action) require one another simple lookup. Demand are based on the need from the application. Is there any reason to build constraints between tables (inside SQLserver) nowadays? If so, when? Most applications in my area are built on object principles and tables are joined on demand.
0 Comments
Leave a Reply. |