Store Mesh in database I hope this is the correct forum but will ask anyway:

I have lots of Mesh data I want to store. Mesh is actually triangles. I hope it's not too of beginner question but wouldn't Geometry type of SQL Server be the best way to store that?

Specifically I'm interested in storing FBX file that are created in other programs sometimes in different formats such Autodesk Revit then converted to FBX. My other option is use file system which is risk and not managed.
Or using binary field but storing large binary data in a database rarely ends well I understand.

This question is not about how to actually load the data I know this could be a problem but what SQL datatype should I use.

I was planning to make the FBX files very small so that for example I can have lookup tables of types. Example: a door will always be a single FBX and then the table will have: FBXType FBXData 1 (door) 2 (furniture)

At the moment is just querying so I can build AssetBundles for Unity. Then I was thinking if it is geometry maybe I can use the smart indexes and functions like intersect that is available for geometry type.

The data will be changing that is the reason I want it in a database however it will probably be in deliveries (this one day of the month everything is updated) and probably new rows (will have another column IsDeleted) can even be a new table but not a must. If splitting by type my colleague says only few FBX files will be large for buildings skeleton but even this is not sure because we can split by floor. Most FBX files will be 5MB or less
Are you considering using SQL Server to query data inside the mesh? For example, are you trying to pass in a list of points, and then have SQL Server figure out whether points in that area match up to any of the mesh data for existing rows inside the database?

If so, you're gonna have a bad time - that's not what SQL Server is designed for.

If, on the other hand, you're just using SQL Server as a key/value store ("give me the mesh data for this desk design") then you can use any data type you like, like JSON or XML or BINARY. You're correct, though, by saying that this rarely ends well. If you're looking for key/value storage, then use a key/value data store instead.