Интересно, очень. Попробую повторить ваш опыт. Если можно, несколько слов об агротехнике: как нормируете урожай, что делаете с пустыми плетями, какая защита от болезней и вредителей.
Кстати, не пробовали выращивать дыни на прививках?
Ещё кстати, для прогрева грядки надо покрывать её не черной агротканью, а прозрачной полиэтиленовой пленкой, пропускающей солнечные лучи, которые греют почву.
Спасибо за комментарий. Spatial index не пробовал использовать, но мне очень интересно сделать замеры, этот индекс кажется перспективным для данной задачи.
PS Первоначально простое решение удовлетворяло, именно поэтому проект развивался по шагам описанным выше.
Согласен, можно использовать и ваш подход. Более того, в технической документации от разработчика есть рекомендация использовать собственные декораторы (например, @Roles()). Спасибо за комментарий.
Спасибо за справедливое замечание, как я писал мы можем обойтись без group by . Group by имеет смысл использовать когда есть вероятность повторения значения поля (например при join других таблиц). В данном случае, вы правильно заметили, поле уникальное. Group by можно не использовать.
В статье я писал: «Но необходимо понимать, что за данную оптимизацию мы платим тем, что мы испытываем сложности с дополнительной сортировкой (например, по алфавиту)». Чтобы избежать внедрения дополнительных полей (помимо sortID), я использовал фильтрацию: по имени (алфавит), по дате...
Прошу учесть, что в миграции я добавлял поле sortID AUTO_INCREMENT. В свою очередь AUTO_INCREMENT: Значение будет увеличиваться для каждой новой строки; Значение уникально, дубликаты невозможны; Если строка удалена, auto_increment столбец этой строки не будет повторно назначен. То есть перерасчёт sortID не требуется. У новой записи всегда будет sortID больше чем у предыдущих (это можно назвать сортировкой по дате создания).
Согласен в первом запросе можно обойтись без group by ID, указал его для наглядности, так как во втором запросе использую group by sortID.
Так же согласен, что необходимо дополнительно подстраховаться и указать ORDER BY в первом запросе.
Интересно, очень. Попробую повторить ваш опыт. Если можно, несколько слов об агротехнике: как нормируете урожай, что делаете с пустыми плетями, какая защита от болезней и вредителей.
Кстати, не пробовали выращивать дыни на прививках?
Ещё кстати, для прогрева грядки надо покрывать её не черной агротканью, а прозрачной полиэтиленовой пленкой, пропускающей солнечные лучи, которые греют почву.
Спасибо за комментарий. Spatial index не пробовал использовать, но мне очень интересно сделать замеры, этот индекс кажется перспективным для данной задачи.
PS Первоначально простое решение удовлетворяло, именно поэтому проект развивался по шагам описанным выше.
Согласен, можно использовать и ваш подход. Более того, в технической документации от разработчика есть рекомендация использовать собственные декораторы (например, @Roles()). Спасибо за комментарий.
Согласен, поле лишнее. Внес правки в статью.
Спасибо за справедливое замечание, как я писал мы можем обойтись без group by . Group by имеет смысл использовать когда есть вероятность повторения значения поля (например при join других таблиц). В данном случае, вы правильно заметили, поле уникальное. Group by можно не использовать.
Так как sortID не является PK для таблицы
Согласен в первом запросе можно обойтись без group by ID, указал его для наглядности, так как во втором запросе использую group by sortID.
К сожалению, PK не всегда бывает сортируемым, в часто uuid. Я показал на примере как внедрить сортируемое поле и в дальнейшем его использовать.
Спасибо за интересный комментарий.<o:p></o:p>
В статье я писал: «Но необходимо понимать, что за данную оптимизацию мы платим тем, что мы испытываем сложности с дополнительной сортировкой (например, по алфавиту)». Чтобы избежать внедрения дополнительных полей (помимо sortID), я использовал фильтрацию: по имени (алфавит), по дате...
Прошу учесть, что в миграции я добавлял поле sortID AUTO_INCREMENT. В свою очередь AUTO_INCREMENT: Значение будет увеличиваться для каждой новой строки; Значение уникально, дубликаты невозможны; Если строка удалена, auto_increment столбец этой строки не будет повторно назначен. То есть перерасчёт sortID не требуется. У новой записи всегда будет sortID больше чем у предыдущих (это можно назвать сортировкой по дате создания).
Согласен в первом запросе можно обойтись без group by ID, указал его для наглядности, так как во втором запросе использую group by sortID.
Так же согласен, что необходимо дополнительно подстраховаться и указать ORDER BY в первом запросе.