Difference between using SMO and SQL queries (through SqlConnection) when building a SQL Server table

Question

I don't really understand the difference between using one or other when creating a table in my SQL Server database. Is one safer or faster than the other when building a table?

Answer 1

I'm not sure that SMO covers every single attribute and property that you'd want to set for a table, and scrounging around to find them all can be an exercise in futility. Personally I would much rather use DDL (CREATE TABLE, ALTER TABLE, etc) not only because I don't have to look up all the properties but also because it helps me reinforce my knowledge of those commands for cases where I don't want to or can't use SMO. But that may just be a preference thing.

As for speed, no difference whatsoever unless you're measuring the parse/interpretation through the SMO layer with a nanosecond stopwatch. It's going to eventually build the same CREATE TABLE command you would write yourself, and send that on to SQL Server.

Answer 2

SMO and DDL statements are used for different purposes, although it can overlap sometimes.

If you want to programatically control your database schema, use SMO. One example is adding 'dynamic' columns, meaning that your system supports adding database columns in runtime and mapping them to your bussiness layer and/or GUI. Another example is controlling index segmentation and raising a red flag when things become hairy.

If you want to create setup script for installation of your app, use TSQL DDL. Much easier and more straightforward.

EDIT

With SMO you get object model and API. Imagine you have to pass through all columns one by one. With SMO you specify which metadata you need, load it and loop over collection of columns. With ADO.NET one would query over INFORMATION_SCHEMA and system tables to get the schema (try getting all the information about foreign keys and look at that code).

Well, for creating a table or adding a column to a table it may not be such a difference, in fact maybe no difference at all. But for administering multiple tables and keys, that would be another story.