[DiscordArchive] so what youre saying is, we should drop dbc's and put all data in sql?
[DiscordArchive] so what youre saying is, we should drop dbc's and put all data in sql?
Original source
so what youre saying is, we should drop dbc's and put all data in sql?
rektbyfaith
09-23-2025, 10:18 PM #1Archived author: [GLFY] Mitche • Posted: 2025-09-23T22:18:06.098000+00:00
Original source
so what youre saying is, we should drop dbc's and put all data in sql?
Original source
pr otw to ts-wow
rektbyfaith
09-23-2025, 10:18 PM #2Archived author: [GLFY] Mitche • Posted: 2025-09-23T22:18:11.864000+00:00
Original source
pr otw to ts-wow
Original source
this was discussed a few times, but the SQL execution time is still worse than in memory dbc table manipulations
rektbyfaith
09-23-2025, 10:33 PM #3Archived author: tester • Posted: 2025-09-23T22:33:00.597000+00:00
Original source
this was discussed a few times, but the SQL execution time is still worse than in memory dbc table manipulations
Original source
if there were live edits to dbcs via the db it would work, but as it kinda goes against the 'build from scratch' mindset, doesn't really fit
rektbyfaith
09-23-2025, 10:33 PM #4Archived author: tester • Posted: 2025-09-23T22:33:21.060000+00:00
Original source
if there were live edits to dbcs via the db it would work, but as it kinda goes against the 'build from scratch' mindset, doesn't really fit
Original source
pretty sure even when using sql it still loads to memory, it's just the storage method of dbc data
rektbyfaith
09-23-2025, 10:36 PM #5Archived author: Titi • Posted: 2025-09-23T22:36:00.671000+00:00
Original source
pretty sure even when using sql it still loads to memory, it's just the storage method of dbc data
Original source
you can just reload dbc memory on demand
rektbyfaith
09-23-2025, 10:36 PM #6Archived author: Titi • Posted: 2025-09-23T22:36:29.636000+00:00
Original source
you can just reload dbc memory on demand
Original source
it would for sqlite, but the actual communications of runtime -> sql server -> apply-> return success is longer than take change -> change hashmap/list
rektbyfaith
09-23-2025, 10:36 PM #7Archived author: tester • Posted: 2025-09-23T22:36:55.079000+00:00
Original source
it would for sqlite, but the actual communications of runtime -> sql server -> apply-> return success is longer than take change -> change hashmap/list
Original source
noggit just migrated to only use SQL for dbc storage and access instead of dbc files. There could be an optino to sync/use emulator dbc tables instead of noggit's
rektbyfaith
09-23-2025, 10:37 PM #8Archived author: Titi • Posted: 2025-09-23T22:37:56.522000+00:00
Original source
noggit just migrated to only use SQL for dbc storage and access instead of dbc files. There could be an optino to sync/use emulator dbc tables instead of noggit's
Original source
yeah but dbcs are realistically a much smaller % of your overhead
rektbyfaith
09-23-2025, 10:38 PM #9Archived author: tester • Posted: 2025-09-23T22:38:25.732000+00:00
Original source
yeah but dbcs are realistically a much smaller % of your overhead
Original source
you shouldn't query database directly, just run some commands on whatever data in memory needs update when needed, and the dbc editing tool could auto run update commands
rektbyfaith
09-23-2025, 10:39 PM #10Archived author: Titi • Posted: 2025-09-23T22:39:05.845000+00:00
Original source
you shouldn't query database directly, just run some commands on whatever data in memory needs update when needed, and the dbc editing tool could auto run update commands
1 Guest(s)
1 Guest(s)