Я давний сторонник производить все вычисления на стороне клиента.
Проще переползать с базы на базу, не загружаем ресурсы базы, проще параллелить, поддерживать, отлаживать.
Тоже самое относится к хранимкам и триггерам, это вообще считаю за зло в современом мире. Нет триггерам и хранимкам!
С sql-базами лучше такого не делать.
Расширение большой таблицы может привести к непредсказуемым результатам., как у Вас.
Вариантов несколько.
- создать дополнительную таблицу со связью 1-1 и нужными полями, ее джойнить по необходимости. Быстор, просто, молодежно.
- создать новую таблицу и в нее перелить данные, ппреливать можно постепенно.
Никогда, никогда, и ни при каких обстоятельствах нельзя использовать автоинкремент. Это абсолютно неправильный паттерн программирования в SQL (да и вообще в базах данных).
Более того, нормальные базы данных автоинкремента не имеют!
Что использовать, спросите Вы? Используйте GUID/UUID и прочие уникальные идентификаторы.
Для каждой записи генерируйте свой, уникальный UUID, и используйте его как первичный-вторичный ключ для ссылок на записи.
1) Положите в проект схему базы и тестовые данные в виде sql-файлов, или сделайте утилиту для их загрузки из какого нибудь json/xml/yaml/edn/etc...
2) Напишите файл Readme.md, в котором опишите настройки, где они лежат и как залить схему и тестовые данные. Укажите требования к проекту, как собрать, какие типы баз использовать, какие версии явы и прочее...
3) Попробуйте собрать свой проект без использования среды разработки, только из консоли с использованием maven, gradle или что вы там используете (ant?).
4) Обязательно укажите запускаемый класс с main-методом, ну или укажите его в в файле-сборки
5) Залейте проект на гитхаб и попросите кого нибудь его протестировать
6) Необязательно, но в тесты тоже иногда смотрят. Если они есть, не отказывайте в удовольствии и их в проект пихнуть.
Ява-программисты, они умные, могут и в мавен, и в градл, и в пропертях поковыряться.
10k в секунду, нормально - это highload, а в сутки - вообще ни о чем ~ 7 запросов в минуту
Заводить под каждый справочник отдельную таблицу - это путь в сторону битрикс и могилы.
Хранить в xml/json - зачем, если есть база данных.
Мне кажется достаточно отдельной таблицы id|name|value|type, ну пары таблиц, еще одна с описанием.
Ну и кешировать все это в redis. Считывать все при старте и загружать в него.
Ваш подход гораздо лучше, как минимум тем, что в какой-то момент наверняка захочется сделать интерсекцию по трекам, ли выбрать точки внутри полигона. А с проблемой производительности можно бороться партиционированием таблиц, например по времени начала трека. Старые партиции стирать и перекидывать в архив. Ваш вариант как минимум гораздо гибче.
Еще раз выражу свою мысль конкретнее, если упомянули :-)
Базу проектируют под типовые запросы, а не просто так. Для их ускорения используют нормализацию. Другими словами - сначала описание бизнес-модели, потом запросов, а уж потом таблицы, индексы и прочее. Конечно же на 1000-100000 записей ничего этого можно и не почувствовать, благо компухтеры уже не те. Но при переходе за шесть нулей - результат чувствуется, да еще как.
Так что рисуем схему и пишем запросы словами. Как пример: пользователь должен видеть склады фирм в радиусе 50км от своего местоположения, отсортированные по расстоянию и отфильтрованные по релевантности товаров от. 1 до 5.
Все достаточно просто, перестаньте думать таблицами и начните думать ДОКУМЕНТАМИ.
У вас есть всего два документа - два индекса. Индекс Пользователей, и индекс Операций.
Пользователь представляет из себя документ со всеми полями таблицы member. А Операция, состоит из конкатенации полей member-operation-operationtype. Да данные в индексе Операции будут дублировать некоторые поля из Пользователей, но это и не страшно, это правильно, так как это фактически лог.
Странно, у меня для русских полей стоит russian аналайзер, из коробки, ищет по словоформам неплохо, но на фамилиях не тестировал. Попробуйте еще и fuzzy query.
Вот прямо сейчас проверил: "лебедь датчик", находит "Светильник Лебеди ночник с датчиком света Космос".
Ищу площадки, получаю "Серая площадка и круглая черн.ручка под замок"
Ищу лампа, находит и лампу и лампой и лампы, и лампа.
Ищу гвоздь, получаю Скоба пластиковая с гвоздем
PS. Elasticsearch 5.1.1 если чо. Специально никаких плагинов с русской морфологией не ставлю с версии 2.x
Как-то давным-давно развлекался с eclipse birt, проект вроде бы активно развивается - www.eclipse.org/birt
Дизайн отчетов делаете в эклипсе, и разворачиваете сервер, куда складываете ваши шаблоны и генерируете отчеты.
Вот таблица сравнения - www.innoventsolutions.com/comparison-matrix.html
Да, jasperreport тоже заводил, но остановился на birt, уж не помню почему, было лет 10 назад.
Алгоритмом работы (lock-based/ versioning), транзакциями, хранимыми процедурами, возможностями sql. Это по крупному, в мелочах - еще больше. Собственно, эти базы данных настолько разные, что сравнивать их напрямую нельзя. Каждая хороша для своего класса задач, хотя для магазина/cms обе будут примерно одинаковы.
Не очень хороший выбор вы сделали. Меняйте apache на nginx, и будет вам щазтие.
Вам нужен реверс-прокси сервер, что nginx делает в разы круче, проще и правильней, чем индеец. Индеец хорош, но не здесь.
Во здесь например - https://www.digitalocean.com/community/tutorials/h...