Pull to refresh
3
Дегтярёв Евгений@bat

Go/PHP Developer

5
Subscribers
Send message
Есть такое.
Помню, когда жил в сельской местности, при подозрении на грозу отрубалась вся мало-мальски стоящая техника + антенну из телевизора вытаскивали. Это как раз тот случай, когда лучше перебдеть чем недобдеть.
На моей памяти был случай. Когда через некоторое время после окончания грозы, даже небо прояснилось, не слабо так шарахнуло. Поплатились все, кто успел включить технику.
Настройки лучше кешировать в памяти.
да, было время.

PS
Сейчас из газировки больше всего нравится грушевый волчихинского пивзавода, не знаю только возят ли его в нск.
Если будет время, дома посмотрю текущее решение и расскажу как решили сами.
Не рекомендую устанавливать базу городов на виртуальный хостинг, не выдержит нагрузки.

проблему с индексами таки не решили
Вы не обращали внимания, что сейчас все анкеты и формы заявлений пр. для согласия на участие в подобных лотереях или акциях, одержат блок информации (мелким шрифтом), подписывая который вы даете согласие на обработку персональных данных?
Во-во… еще в 90-х началось.
Помню, что базы адресатов пополнялись наивными родственниками и знакомыми, которые любезно сливали адреса и фамилии за обещание дополнительных плюшек.
у вас не используются индексы.
индекс есть, но он бесполезен.
Если под .dat файлом подразумевается бинарный файл от maxmind — то, однозначно, родное API под нужную платформу.

Решение на MySQL надо еще суметь приготовить, у топикстартера здесь полный провал.
Для тех, кому достаточно английской базы, но важна скорость — посмотрите в сторону модуля nginx GeoIP. Там используется эта же база maxmind.

тут можно и mod_geoip заюзать, геолокация далеко не накаждой странице нужна.

P.S.
А зачем все это в mysql? почему не оставить в формате maxmind?
Чтобы проанализировать, смоделировать, протестировать нужно время, а конкретная задача, как правило, имеет четко поставленные цели и сроки. «Может быть» подразумевает ненулевую вероятность возникновения такой ситуации и если она возникнет, то, скорее всего, во время эксплуатации, когда исправление ошибки в разы дороже, чем во время разработки. Использование же суррогатного ключа исключает такие ситуации и дополнительное поле + индекс не такая большая плата за это.

сомнителен, когда придуманы последовательности (sequences)
провели тесты — все зашибись, тормозов нет.
не факт что так и будет всегда и со временем не появятся новые, более тяжелые связи.
если одну запись по ключу то не заметно, а вот при джойнах и сортировках очень даже.
PS
для меня вообще сомнителен смысл кляузы auto_increment в объявлении поля.
обновлением ссылок при изменении поля внешнего ключа должен заниматься ON UPDATE CASCADE этого внешнего ключа. Другой вопрос, что его в 99% случаев игнорируют.

и правильно делают, т.к. изменения могут быть очень масштабными.
Не подскажите, где можно скачать бесплатный чай? :)
И вариться в своем соку?

Information

Rating
Does not participate
Location
Алтайский край, Россия
Registered
Activity

Specialization

Бэкенд разработчик