Please follow basic Netiquette and post the DDL we need to answer this. Follow industry and ANSI/ISO standards in your data. You should follow ISO-11179 rules for naming data elements. You should follow ISO-8601 rules for displaying temporal data (https://xkcd.com/1179/). We need to know the data types, keys and constraints on the table. Avoid dialect in favor of ANSI/ISO Standard SQL.
Transaction size is unlikely to be the primary cause of import slowness. There are legitimate reasons to break up transactions, even within a single table or to import a whole set of tables in a single transaction as you do http://www.sqlskills.com/blogs/kimbe...og-throughput/
The numbers you are postulating aren't all that out of line for todays database systems. What are your concerns? That SQL server wouldn't be able to handle a table with
rows? Yes, you have to be sure to index the table properly and you may want to look into partitioning to spread the data out over multiple files. I wouldn't be overly concerned with the size. I'd be most concerned with your design and how you plan to manage the data.