A couple different options...
We have written applications which will process a spreadsheet and create a new form for each row. Is this something that will be done on a regular basis or is this just a one time action to transition from Excel to InfoPath? How many rows are you dealing with?
Putting your Data in SQL is probably the best, since it gives you the most options. We use the Database Accelerator a lot to have our InfoPath data in SQL as well to enable interfacing and reporting. Qdabra Database Accelerator Suite Version 2.1 - Developer
You would have to completely redo your form to link it to a database via the standard Infopath mechanism. You would want to use web services so you would not have to do this.
Have you thought about making one form that lets you browse your records and edit or view them without having one form per individual record? Using SQL on the backend allows you this kind of interface with your data. So instead of having to open each individual InfoPath form you can have one catalog form which you can then move through the records as you need without closing InfoPath or going to another application like Sharepoint.
If you would like to see a sample of this or have further architecture questions you can send me an email.