[DiscordArchive] yeah it isn't a large difference, it's just why put it in both places, when i already need to start
[DiscordArchive] yeah it isn't a large difference, it's just why put it in both places, when i already need to start
Original source
yeah it isn't a large difference, it's just why put it in both places, when i already need to start with raw file to get blizzlike, and then i still need to write dbcs anyways for client - why add the extra step of adding them to database?
rektbyfaith
09-23-2025, 10:43 PM #1Archived author: tester • Posted: 2025-09-23T22:43:51.980000+00:00
Original source
yeah it isn't a large difference, it's just why put it in both places, when i already need to start with raw file to get blizzlike, and then i still need to write dbcs anyways for client - why add the extra step of adding them to database?
Original source
yeah with c#, it's obviously faster in C++
rektbyfaith
09-23-2025, 10:43 PM #2Archived author: Titi • Posted: 2025-09-23T22:43:53.508000+00:00
Original source
yeah with c#, it's obviously faster in C++
Original source
Pretty sure most of the slow down in my exporter is the hardcoded small page size to accomidate people with a small max_allowed_packet
rektbyfaith
09-23-2025, 10:44 PM #3Archived author: stoneharry • Posted: 2025-09-23T22:44:35.806000+00:00
Original source
Pretty sure most of the slow down in my exporter is the hardcoded small page size to accomidate people with a small max_allowed_packet
Original source
well with database you can more easily reload a specific row/value. also for editing, dbc file needs to be opened, saved, deployed to server etc...
rektbyfaith
09-23-2025, 10:45 PM #4Archived author: Titi • Posted: 2025-09-23T22:45:01.283000+00:00
Original source
well with database you can more easily reload a specific row/value. also for editing, dbc file needs to be opened, saved, deployed to server etc...
Original source
you can actually query that from database to adapt
standard now is 64mb which is nearly all tables combined
rektbyfaith
09-23-2025, 10:45 PM #5Archived author: Titi • Posted: 2025-09-23T22:45:48.650000+00:00
Original source
you can actually query that from database to adapt
standard now is 64mb which is nearly all tables combined
Original source
i can see that being useful in a different enviroment than tswow since it doesn't really matter to overwrite
rektbyfaith
09-23-2025, 10:45 PM #6Archived author: tester • Posted: 2025-09-23T22:45:52.635000+00:00
Original source
i can see that being useful in a different enviroment than tswow since it doesn't really matter to overwrite
Original source
wasn't this a change apart of when they stopped telling column sizes
rektbyfaith
09-23-2025, 10:46 PM #7Archived author: tester • Posted: 2025-09-23T22:46:12.556000+00:00
Original source
wasn't this a change apart of when they stopped telling column sizes
Original source
int(20) is now just int
rektbyfaith
09-23-2025, 10:46 PM #8Archived author: tester • Posted: 2025-09-23T22:46:19.780000+00:00
Original source
int(20) is now just int
Original source
anyways, from my experience sending it all at once is actually slower than in bulk of like 2000 rows.
rektbyfaith
09-23-2025, 10:46 PM #9Archived author: Titi • Posted: 2025-09-23T22:46:23.436000+00:00
Original source
anyways, from my experience sending it all at once is actually slower than in bulk of like 2000 rows.
Original source
I refer back to my _dbc workflow_ document I put on github. DBCs were never designed for patching, it's a write-once format. Blizzard stored their data in OracleDB -- that's changed over the years but it's always been backed by SQL. It just makes sense, you get so many benefits.
Of course, use what works for you. But I don't see the use-case for patching DBCs.
rektbyfaith
09-23-2025, 10:46 PM #10Archived author: stoneharry • Posted: 2025-09-23T22:46:57.761000+00:00
Original source
I refer back to my _dbc workflow_ document I put on github. DBCs were never designed for patching, it's a write-once format. Blizzard stored their data in OracleDB -- that's changed over the years but it's always been backed by SQL. It just makes sense, you get so many benefits.
Of course, use what works for you. But I don't see the use-case for patching DBCs.
1 Guest(s)
1 Guest(s)