Re: Перенести данные из файла в базу данных
Добавлено: 2012.01.19, 12:19
Я уже говорил о том, что никого не заставляю использовать мои советы, каждый волен решать сам что ему лучше.
Напоследок в эту тему скажу
1. Добавить/удалить/изменить пару полей во временной таблице гораздо проще чем переписывать кусок кода в PHP, ну это так чисто мое мнение.
2. Я не буду делать 20000 запросов чтобы выяснить что 2000 не изменилось, я просто сделаю update всех 20000 записей и мне все равно кто обновился, а кто нет. Что страшного случится в том, что вы обновите запись в которой данные не изменились? Те кто обновился будут обновлены, те кто не обновился будут тоже обновлены с точки зрения базы, но останутся неизменными с точки зрения содержащихся в них данных. Часто бывает проще и выполнится быстрее тупо сделать 2000 лишних обновлений, чем накручивать мегаалгоритмы разбирательства что там изменилось, а что нет. Если говорить о MySQL, он не поддерживает join в update, поэтому эта задача решается путем удаления всех записей по pkey, которые есть во временной таблице и вставка нового набора измененных записей. Если на боевой таблице имеются внешние ключи от других таблиц, то на время выполнения обновления можно внешние ключи отключить/удалить, а потом включить/создать.
Я понимаю что трудно сломать собственную логику воспитанную на общепринятых алгоритмах, мне это тоже не сразу далось, но когда я это сделал программить стало в разы легче, хотя и до этого было легко.
Приведу один занимательный пример.
Как-то контора в которой я работал заказала разработку системы распределения прав взамен существующей. Делали эту систему люди которых я лично знаю и имею весьма высокое мнение о их профессиональных навыках, местами эти навыки я оцениваю выше чем у меня.
Приехали они сдавать, запустили вычисление прав на базе в 200 метров и нам просто надоело ждать через 45 минут данного вычисления, а таких запросов боевой сервер должен выполнять несколько сотен в минуту. Боевая база 2 GB + 200MB в месяц, у боевого сервера в 2 раза больше ядер и памяти чем у разработческого. Обсудили варианты, мои оппоненты были за кэширование - логичное но не всегда правильное решение, я за генерацию SQL запросов на лету, которые не используют книжную теорию вычисления прав исходя из принципа что для того, чтобы определить набор к которому есть доступ, нужно вычислить права ко всему набору и отдать только те к кому доступ есть. Через 40 минут программинга их код смог отработаться за 8 минут, мой пилот за 12 миллисекунд, люди были просто в полном ауте, они просто не могли представить что эту задачу можно решать не стандартными методами, как говорится как по книжке и математически "правильно". После того как они подпилили мой пилот, он стал работать 2 миллисекунды на боевой базе.
Кстати судя по логам фреймворка, система вычисления прав пользователей использует последовательны обход дерева AuthItemChild - пример не эффективности и использования методов как по книжке, проще использовать метод последовательного приближения, с помощью которого делается столько SQL запросов, сколько максимальная глубина дерева для данной последовательности, в рекурсивном методе используется столько SQL запросов, сколько узлов в дереве. Кто хочет может завести отдельную ветку для этого.
Мне вообще не хочется вести holywar'ы тут или где еще либо, я высказываю свое мнение и заметьте никогда его не навязываю, если возникают оппоненты по делу, то принимаю участие в дискуссии, вдруг я заблуждаюсь, но доказывать из принципа я не собираюсь.
Напоследок в эту тему скажу
1. Добавить/удалить/изменить пару полей во временной таблице гораздо проще чем переписывать кусок кода в PHP, ну это так чисто мое мнение.
2. Я не буду делать 20000 запросов чтобы выяснить что 2000 не изменилось, я просто сделаю update всех 20000 записей и мне все равно кто обновился, а кто нет. Что страшного случится в том, что вы обновите запись в которой данные не изменились? Те кто обновился будут обновлены, те кто не обновился будут тоже обновлены с точки зрения базы, но останутся неизменными с точки зрения содержащихся в них данных. Часто бывает проще и выполнится быстрее тупо сделать 2000 лишних обновлений, чем накручивать мегаалгоритмы разбирательства что там изменилось, а что нет. Если говорить о MySQL, он не поддерживает join в update, поэтому эта задача решается путем удаления всех записей по pkey, которые есть во временной таблице и вставка нового набора измененных записей. Если на боевой таблице имеются внешние ключи от других таблиц, то на время выполнения обновления можно внешние ключи отключить/удалить, а потом включить/создать.
Я понимаю что трудно сломать собственную логику воспитанную на общепринятых алгоритмах, мне это тоже не сразу далось, но когда я это сделал программить стало в разы легче, хотя и до этого было легко.
Приведу один занимательный пример.
Как-то контора в которой я работал заказала разработку системы распределения прав взамен существующей. Делали эту систему люди которых я лично знаю и имею весьма высокое мнение о их профессиональных навыках, местами эти навыки я оцениваю выше чем у меня.
Приехали они сдавать, запустили вычисление прав на базе в 200 метров и нам просто надоело ждать через 45 минут данного вычисления, а таких запросов боевой сервер должен выполнять несколько сотен в минуту. Боевая база 2 GB + 200MB в месяц, у боевого сервера в 2 раза больше ядер и памяти чем у разработческого. Обсудили варианты, мои оппоненты были за кэширование - логичное но не всегда правильное решение, я за генерацию SQL запросов на лету, которые не используют книжную теорию вычисления прав исходя из принципа что для того, чтобы определить набор к которому есть доступ, нужно вычислить права ко всему набору и отдать только те к кому доступ есть. Через 40 минут программинга их код смог отработаться за 8 минут, мой пилот за 12 миллисекунд, люди были просто в полном ауте, они просто не могли представить что эту задачу можно решать не стандартными методами, как говорится как по книжке и математически "правильно". После того как они подпилили мой пилот, он стал работать 2 миллисекунды на боевой базе.
Кстати судя по логам фреймворка, система вычисления прав пользователей использует последовательны обход дерева AuthItemChild - пример не эффективности и использования методов как по книжке, проще использовать метод последовательного приближения, с помощью которого делается столько SQL запросов, сколько максимальная глубина дерева для данной последовательности, в рекурсивном методе используется столько SQL запросов, сколько узлов в дереве. Кто хочет может завести отдельную ветку для этого.
Мне вообще не хочется вести holywar'ы тут или где еще либо, я высказываю свое мнение и заметьте никогда его не навязываю, если возникают оппоненты по делу, то принимаю участие в дискуссии, вдруг я заблуждаюсь, но доказывать из принципа я не собираюсь.