Timeline for Store Mesh in database
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 7, 2017 at 14:53 | comment | added | joanolo | I see your point. Good. I guess that a number of those problems are going to happen on any data store that has replication (although they may make less use of log files because there are [normally] less ACID guarantees). AFAIK, a mesh, as used in CAD or Simulation programs, can be really large, but you do not normally change it that often... I guess a good compromise might be to store pieces of data, assuming you do not change everything every time. | |
| Jan 7, 2017 at 14:43 | comment | added | Brent Ozar | The problem is the transaction log. If your values are large and they change often, you're going to be pouring that data into the log file, bloating your log file backups, making DR replication more challenging, etc. | |
| Jan 7, 2017 at 14:11 | comment | added | joanolo | (You can normally use any contemporary SQL database as a key/value store with reasonable --if not optimal-- efficiency; and it might make sense if you also use it to store many other things.) | |
| Jan 7, 2017 at 14:08 | history | answered | Brent Ozar | CC BY-SA 3.0 |