Слишком многим оставляют Соединения запах кода?
Вы близко. Дайте этому шанс:
For i = LastRow To firstDataRow Step -1
' collect all rows to be deleted in range r
If Cells(i, eraseCol).Value Then
If r is Nothing Then set r = cells(i,eraseCol) else: Set r = union(r,Cells(i,eraseCol))
End If
Next
r.EntireRow.Delete
N.B - поскольку вы собираете только ячейки в диапазоне, вы можете зацикливаться вперед, если хотите; но цикл в обратном направлении все равно будет работать
8 ответов
Here's my personal list. I don't claim that these points are incredibly well researched, but these are the major gripes I've had with them based on my usage patterns.
- Monotone: Having to specify "." to mean the current working directory (otherwise, any command applies to the whole working copy).
- CVS: Too many to list. Avoid at all costs. (probably the permission handling, though).
- Subversion: Not distributed.
и может быть заменено на
EXISTSилиNOT EXISTS(если вы только хотите выяснить, что соответствующие записи существуют или не существуют в других таблицах).См. эту статью в мой блог для подробностей работы:
- Поиск неполных заказов - как извлечь выгоду из замены
СЛЕДУЮЩЕГО СОЕДИНЕНИЯнаНЕ СУЩЕСТВУЕТ
- Поиск неполных заказов - как извлечь выгоду из замены
В том смысле, что вы можете / должны это исследовать, я бы сказал, да. Скорее всего, вы можете получить лучшую утилиту и обслуживание, если учесть некоторые из них.
В том смысле, что это «плохой код», нет, это вполне может быть разумным, особенно для больших БД, а современные базы данных, скорее всего, оптимизируют любую неэффективность. .
Нет, это совершенно нормально, хотя, если вы снова и снова пишете одни и те же запросы / процедуры, используя одни и те же объединения к одним и тем же таблицам, это может быть кандидатом на создание View только для того, чтобы упростить ваши запросы в будущем и уменьшить количество точек касания, которые вам нужно изменить, если вы измените схему
Во многих случаях вы можете смягчить визуальный запах, создавая вспомогательные виды, я не думаю, что существует жесткое и быстрое правило о том, сколько левых объединений считается плохим.
В отличие от процедурных кодирование, разбиение SQL на мелкие кусочки может привести к неэффективным запросам.
Для кого-то почти невозможно ответить на такой общий вопрос, как этот, и попытаться создать такое произвольное правило было бы бессмысленным.
Левые объединения - совершенно приемлемый тип объединения, который сопоставьте очень распространенную потребность: принесите мне все x, если они связаны с y, то получите и их.
Ваши результаты Мои перемены
Все необычное может быть кодовым запахом для чего угодно. Как сказал Кассной, это может быть совершенно законно. Для действительно всесторонних отчетов весьма обычно требовать сумасшедшего количества объединений, чтобы правильно собрать информацию. Это не означает, что разработчик должен смотреть на денормализацию своей базы данных.
Нет, совсем нет. Совершенно законно построить структуру базы данных, которая использует значительное количество левых объединений в некоторых запросах.
Сказав, что я, как правило, предпочел бы создать базу данных таким образом, чтобы количество случаев, когда требуются внешние объединения, было ограниченным по мере развития опыта. предположить, что (сложные) запросы, использующие их, более подвержены ошибкам и могут вызвать проблемы с обслуживанием.
Как интересный исторический момент, ранние версии IBM DB2, когда они работали только на мэйнфреймах, не поддерживали внешние объединяет (Oracle и Ingress оба сделали в то время, что было основным пунктом продажи). Это привело к некоторым интересным проблемам в проектировании базы данных, поскольку было необходимо обеспечить, чтобы все ожидаемые требования к доступу к базе данных могли быть решены с помощью только внутренних объединений.
Я бы сказал, что необходимость использовать множество объединений (например, работать с нормализованными данными) - это не запах кода, а скорее признак того, что вы работаете не в нужном месте. По моему опыту, те, кого беспокоит количество объединений в запросах, слишком много развивают в базе данных и недостаточно в приложениях и отчетах, которые предоставляют данные. Структуры данных должны быть достаточно гибкими, чтобы поддерживать множество применений, и именно поэтому нормализация, в той или иной степени, важна.
При создании сегодняшних корпоративных приложений разработчики могут использовать вчерашние достижения для работы на абстрактных уровнях, высоко над технологиями. как SQL и даже XML, чтобы приносить больше пользы с меньшими затратами. Есть инструменты, например, средства записи отчетов, генераторы кода, ORM, структуры сущностей и т. Д. которые абстрагируются от низкоуровневой работы по построению SQL вручную и будут выполнять соединения за вас. Большинство знает об используемом диалекте SQL (например, Oracle 9 против MySQL 3) и может сгенерировать синтаксис SQL, наиболее эффективный для этого диалекта; это означает, что они, вероятно, могут создавать соединения лучше, чем вы.
Однако эти инструменты работают очень плохо или вообще не работают в реляционной среде без достаточной нормализации. Для меня здесь проявляется запах «развития»; Если устоявшийся инструмент доступа к данным не может понять отношения, в соответствии с которыми я структурировал свои данные, мне, вероятно, нужно искать более нормализованный способ создания этих отношений, и в этом случае получить выгоды, намного превосходящие просто использование инструмента. Обычно где-то между 2-й и 3-ей нормальной формой является золотая середина; хотя всегда есть небольшие области реляционных данных, где более высокая степень нормализации имеет смысл и добавляет ценность.
Ура, Трэвис