There's an approach called the "data separation model". It uses two files: File1 contains the interface (layouts, scripts, value lists) and File2 stores the actual data tables. The table occurrences in File1 each have an external data source reference to a table in file2.
The assumption behind this design is that most updates will require changes to file1--the interface file and not to file2--the data file. New versions of the interface file can simply be put in place of the older version and no importing of data is required.
This approach simplifies deploying an updated copy of your solution but requires a more complext design. If you have just one user for your solution and the time needed to import records is reasonable, you probably won't need this approach.
If you have multiple users and/or data that takes hours to import, then the data separation method makes sense to use.
For how to convert a single file solution into a two file interface and data system, see this thread: Convert to Seperation Model
Is there any problem or special considerations if I wish to have the data reside in a SQL Server Database? Can Filemaker be used as a front-end for importing data to and reporting on data in SQL Server databases?
It's a more complex setup, but essentially, that's another form of the data separation model, but now your data file is replaced by the SQL Server Database. The challenge is in setting up a working ODBC connection and getting any needed SQL queries to work for you.