В большом количестве вакансий, не связанных напрямую с программированием часто требуется знание SQL — например, в аналитике. В этом случае используемая СУБД, к которой будут задаваться запросы, будет конечным продуктом для таких пользователей.
Не путайте теплое с мягким: C — это язык для разработчиков, то есть специально обученных программированию людей, которые должны разбираться в тонкостях их специальности. А MySQL — это конечный продукт для пользователя, не обязательно разбирающегося в программировании и результаты выполнения его операций должны быть строго специфицированы и понятны. Поэтому такие вещи в MySQL, по-хорошему, недопустимы. А для C — это нормально.
Действительно, тот случай, когда данные прекрасно отображаются на реляционную модель. Проверенные временем SQL решения тут будут работать отлично, обеспечивая приемлимый уровень производительности и надежности. Важно не городить огород из самых модных систем, а использовать то, что лучше подходит для конкретного случая.
Ну в свою защиту еще могу сказать, что пока все это дело писалось, все алгоритмы запускались большое количество раз, и результаты на ненагруженной системе всегда были почти одинаковыми)
> несколько часов — это еще хорошо, что не несколько дней
Был бы второй комп, можно было бы и больше тестировать) А так, самый большой промежуток что я могу не трогать систему — это время сна)
Статистика конечно не огромная, но в моем понимании для получения общей картины вполне достаточная. Как я уже писал, на каждом тестовом наборе все алгоритмы запускались по три раза, и выбиралось минимальное время из этих запусков. Собственно так я пытался избавиться от всяких непредусмотренных нагрузок. Плюс все это дело запускалось на ночь, систему я сам дополнительно никак не грузил.
Если бы была возможность, тестировал бы больше, но, к сожалению, чтобы прогнать все представленные тесты и так потребовалось несколько часов.
И вдобавок, на каждом наборе тестовых данных все алгоритмы запускались по очереди, так что долговременные бекграунды не должны были избирательно повлиять на некоторые алгоритмы)
Из классических алгоритмов выбор пал только на heapsort и quicksort из-за того, что первый идейно близок к smoothsort, а второй является самым быстрым из них. Подозреваю, что «чистый» mergesort находился бы где-то в районе shellsort — heapsort на графиках, хотя точно сказать не могу, не проверял. А распараллеливание — это уже отдельная большая тема для рассмотрения, честно, даже не подумал об этом)
> несколько часов — это еще хорошо, что не несколько дней
Был бы второй комп, можно было бы и больше тестировать) А так, самый большой промежуток что я могу не трогать систему — это время сна)
Если бы была возможность, тестировал бы больше, но, к сожалению, чтобы прогнать все представленные тесты и так потребовалось несколько часов.
И вдобавок, на каждом наборе тестовых данных все алгоритмы запускались по очереди, так что долговременные бекграунды не должны были избирательно повлиять на некоторые алгоритмы)