ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Интересует ваше мнение о двух разных подходах
42 сообщений из 42, показаны все 2 страниц
  все  
Интересует ваше мнение о двух разных подходах
    #39792993
Sashaua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sashaua
Участник
Всем привет.
Интересует ваше мнение о двух разных подходах. Сейчас одной ногой сижу на поддержке двух разных проектов (Delphi+firebird) для конторы (написаны не мной и писались двумя разными людьми), время от времени у бизнеса возникают хотелки которые я реализовываю.
В одном проекте компоненты для работы с базой "накиданы" дизайнере.
В другом проекте (использются классы, методы итд.) компоненты для работы с базой создаються динамиччески.
При запросе в базу, метод создает транзакцию кверю и отдает данные, после компоненты удаляются.
И в некоторых местах где например в интерфейсе есть набор фильтров и баттон "Применить" (по которому дергается какойто из методов) пользователь может выбирать разные фыльтры и сколько угодно раз жмякать "Применить" есть проверка, если компонент уже создан то он уничтожается и все пересоздается, и все поехало по новой.
Интересует мнение насколько этот подход оправдан.
...
Рейтинг: 0 / 0
28.03.2019, 15:04
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793006
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Sashaua,

Во втором подходе, похоже, была попытка отделить логику от интерфейса. Это хорошо и так и надо. Т.к. интерфейсы могут быть разными.
...
Рейтинг: 0 / 0
28.03.2019, 15:16
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793051
DimaBr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaBr
Участник
Я бы ради интереса поставил логирование. Сколько раз пользователь(ли) меняет набор фильтров. Может те, кто это умел уже ушли, а новые не в зуб ногой и функция устарела
...
Рейтинг: 0 / 0
28.03.2019, 15:53
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793055
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SashauaИнтересует мнение насколько этот подход оправдан.
Скажем так, он оправдан, когда программисту нехрен делать, всё слишком хорошо и безошибочно работает и сложно чувствовать себя крутым.
...
Рейтинг: 0 / 0
28.03.2019, 15:58
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793098
Любезный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Любезный
Участник
авторИ в некоторых местах где например в интерфейсе есть набор фильтров и баттон "Применить" (по которому дергается какойто из методов) пользователь может выбирать разные фыльтры и сколько угодно раз жмякать "Применить" есть проверка, если компонент уже создан то он уничтожается и все пересоздается, и все поехало по новой.
Считаю, что подход плохой.
1. Трата времени и ресурсов на пересоздание.
2. Если переоткрываются транзакции - дополнительно увеличивается их счетчик идентификаторов, что при большом количестве транзакций может со временем создать проблемы.
Плюс (и то не всегда) только в том, что проще перейти на другую технологию работы с БД - меньше кода переписывать.
...
Рейтинг: 0 / 0
28.03.2019, 16:22
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793104
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Любезныйменьше кода переписывать.
Экстремально странное утверждение. Максимум, чего можно достичь - "не слишком больше кода переписывать", и то только в тех проектах, в которых код хорошо написан (чего на практике при таком подходе никогда не бывает).
...
Рейтинг: 0 / 0
28.03.2019, 16:25
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793114
Любезный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Любезный
Участник
авторМаксимум, чего можно достичь - "не слишком больше кода переписывать", и то только в тех проектах, в которых код хорошо написан (чего на практике при таком подходе никогда не бывает).
Если при нажатии кнопки дергается метод, реализация которого физически находится в другом модуле - переписывать нужно только код этого другого модуля. Во всяком случае, это проще, нежели чем рисковать портить еще и интерфейс.
...
Рейтинг: 0 / 0
28.03.2019, 16:33
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793121
Любезный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Любезный
Участник
Блин, что-то я туплю. Конечно, отрыв кода интерфейса от логики и пересоздание компонентов - совершенно разные вещи. Выделение логики отдельно от интерфейса - необходимость для проектов, которым нужно развиваться. Пересоздание компонентов с реинициализацией всего и вся - на мой взгляд, плохой подход.
...
Рейтинг: 0 / 0
28.03.2019, 16:40
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793125
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Любезныйпереписывать нужно только код этого другого модуля.
От этого переписываемого кода не становится меньше.

ЛюбезныйВо всяком случае, это проще, нежели чем рисковать портить еще и интерфейс.
Новое странное утверждение про "ещё и". При этом Вы вообще позабыли про рассмотрение в разрезе "дизайненные vs создаваемые на ходу компоненты" и почему-то перешли к рассмотрению совершенно перпендикулярного разреза "один файл или разные". Такое ощущение, что Вы почему-то считаете, что "дизайненные" - это "один файл", а "создаваемые на ходу" - это разные, хотя с вероятностью в 50% будет строго наоборот.

Ну а в целом - накидывать хренову уйму ненужного тупого кода это да, проще. Поэтому многие так и делают. Вот только "проще" - не значит "лучше".
...
Рейтинг: 0 / 0
28.03.2019, 16:42
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793250
L1G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L1G
Участник
Sashaua,
ваш вопрос из серии религиозных - каждый будет защищать свой любимый подход.

Вам в некотором смысле повезло - вы занимаетесь поддержкой и того, и другого. Через некоторое время вы сами сможете ответить на вопрос "какой из подходов лучше с точки зрения поддержки?"
(При первоначальной разработке (касательно её простоты и скорости) ответ может оказаться другим, но обычно считают, что удобство поддержки важнее, т.к. обычно в конечном счете на неё уходит больше ресурсов.)

С точки зрения автоматизированного тестирования, например, второй подход лучше, хотя и он недостаточен: бизнес-логика должна быть отделена как от интерфейса, так и от логики хранения данных. (Но кого это волнует, если тестирование ручное или вообще его делает заказчик/пользователь?)
...
Рейтинг: 0 / 0
28.03.2019, 18:31
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793257
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
L1GС точки зрения автоматизированного тестирования, например, второй подход лучше, хотя и он недостаточен: бизнес-логика должна быть отделена как от интерфейса, так и от логики хранения данных.
В этих словах Вы ухитрились допустить сразу две ошибки. Во-первых, как уже обсудили выше, отделение бизнес-логики либо чего-то другого никак не зависит от сравниваемых подходов и равно может присутствовать либо отсутствовать в любом из них. Во-вторых же, у Вас ложные представления об автоматизированном тестировании. Судя по тому, что Вы сказали, Вы имели в виду юнит-тестирование. Однако, юнит-тестирование приложений работы с БД нерационально, в то время как автоматизированное тестирование куда шире, применимо для подобных приложений и равно способно тестировать как "отделённые", так и "совмещённые" приложения.
...
Рейтинг: 0 / 0
28.03.2019, 18:44
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793269
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Любезныйотрыв кода интерфейса от логики и пересоздание компонентов - совершенно разные вещи.
Выделение логики отдельно от интерфейса - необходимость для проектов, которым нужно
развиваться. Пересоздание компонентов с реинициализацией всего и вся - на мой взгляд,
плохой подход.

Поэтому уже лет 20 как придумали TDataModule, которые сочетают инкапсуляцию методов
доступа к базе и "накидывание компонентов мышкой".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.03.2019, 18:56
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793310
L1G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L1G
Участник
softwarerL1GС точки зрения автоматизированного тестирования, например, второй подход лучше, хотя и он недостаточен: бизнес-логика должна быть отделена как от интерфейса, так и от логики хранения данных.
В этих словах Вы ухитрились допустить сразу две ошибки. Во-первых, как уже обсудили выше, отделение бизнес-логики либо чего-то другого никак не зависит от сравниваемых подходов и равно может присутствовать либо отсутствовать в любом из них. Во-вторых же, у Вас ложные представления об автоматизированном тестировании. Судя по тому, что Вы сказали, Вы имели в виду юнит-тестирование. Однако, юнит-тестирование приложений работы с БД нерационально, в то время как автоматизированное тестирование куда шире, применимо для подобных приложений и равно способно тестировать как "отделённые", так и "совмещённые" приложения.

"Во-вторых", я имел в виду вовсе не юнит-тестирование, а тестирование более крупных функциональных блоков (хотя не уверен, можно ли его считать интеграционным). Конкретнее - такое, при котором для скорости реальную СУБД приходится подменять тестовым хранилищем данных в ОЗУ.

Насчет "во-первых" - действительно, автор говорил только про использование визуального дизайнера для БД-компонент. То, что при этом использовались еще и db-aware controls с заданной в их свойствах привязкой к БД-компонентам - это уже моё предположение. Верное или нет - пока неизвестно.
...
Рейтинг: 0 / 0
28.03.2019, 20:10
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793316
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
L1G"Во-вторых", я имел в виду вовсе не юнит-тестирование, а тестирование более крупных функциональных блоков (хотя не уверен, можно ли его считать интеграционным).
Для тестирования "более крупных функциональных блоков" разделение некритично. Там, где тестируется блок - он может состоять из нескольких функций в разных файлах, он может состоять из нескольких функций в одном файле, он может состоять из одного ужасного обработчика Button1Click - код тестирования и не заметит разницы, он в любом случае "просто что-то вызывает".

L1GКонкретнее - такое, при котором для скорости реальную СУБД приходится подменять тестовым хранилищем данных в ОЗУ.
Кошмар. Скажу деликатно: ценность такого тестирования нулевая. Точнее - отрицательная, поскольку на него тратятся вполне конкретные время и деньги.

L1GНасчет "во-первых" - действительно, автор говорил только про использование визуального дизайнера для БД-компонент. То, что при этом использовались еще и db-aware controls с заданной в их свойствах привязкой к БД-компонентам - это уже моё предположение. Верное или нет - пока неизвестно.
Независимо от того, верно оно или нет, это не имеет никакого отношения к возможности автоматизированного тестирования. Используются dbaware - значит, авторы проекта ещё более недураки, вот и всё.
...
Рейтинг: 0 / 0
28.03.2019, 20:22
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793326
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
SashauaПри запросе в базу, метод создает транзакцию кверю

весь вопрос - как создаёт.
если в каждом классе по разному - то ой.

а если там создание в одном месте (например в общем классе-предке, типа Active Record), то при изменении, например, библиотеки доступа к БД - потребуется только это место переписать (я говорю именно про создание, время жизни и т.д. Конкретные методы и свойства тип prepare запросов в разных библиотеках называются по разному, но и это можно в общий предка метод вынести).

Sashauaнапример в интерфейсе есть набор фильтров и баттон "Применить"
....то для всех возможных комбинаций всхе возможных фильтров по отдельному TQuery на форму не кинешь все равно. И придётся либо на клиенте накладывать фильтр поверх "select * from table;" - Briefcase, TClientDataset, etc. Либо таки генерить SQL. В последнем случае создавать ли компонент или бросить его на форма, настроить ему все свойства и менять только SQL - какая разница?

ЛюбезныйТрата времени и ресурсов на пересоздание.

ОТОЖ! ведь пока Pentium мучается, создавая объект TQuery - пользователи уже по 100 раз поменяют наборы и значения фильтров.
...
Рейтинг: 0 / 0
28.03.2019, 20:48
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793363
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Для себя выработал такое правило. Если требуется отобразить данные в dbgrid, то проще кинуть на форму датасет и датасоурс. Именно на форму, а не на модуль данных. В модуле данных только общие для приложения ресурсы, например подключение к бд. Но в основном работа с бд выполняется динамически. Использую ibxFbUtils, что делает код весьма компактным. При этом учитываю, что prepare - это очень медленный этап при плохой сетке. Также стараюсь по возможности разрабатывать классы, например TUser, TContragent, и т.п. и в их методах реализовать всю работу с бд. В этом случае сложность программы уменьшается на порядки и никакой ORM не нужно.
...
Рейтинг: 0 / 0
28.03.2019, 23:37
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793372
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Для небольших задач (или подзадач) часто удобно всю работу с базой выносить в отдельный модуль(ли) с классом(ми), при создании которого ничего не происходит, а при обращении к свойствам/методам - создается что надо, если еще не создано. В деструкторе же все освобождается.
Очень удобно потом в разных потоках создавать этот класс, не нужно никакой синхронизации.
Ну и поменять субд просто, понятное дело.
...
Рейтинг: 0 / 0
29.03.2019, 01:20
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793499
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
DmSerTContragent, и т.п. и в их методах реализовать всю работу с бд
....
Ariochнапример в общем классе-предке, типа Active Record

Насколько понимаю, тот же mORMot построен на этом принципе
...
Рейтинг: 0 / 0
29.03.2019, 11:48
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793513
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochЛибо таки генерить SQL. В последнем случае создавать ли компонент или бросить его на форма, настроить ему все свойства и менять только SQL - какая разница?
Менять SQL не надо. Достаточно одной строки наподобие

Код: pascal
1.
Query.MacroByName('filter').Text := Filter.CreateSQL;



И какая разница... да, в общем, такая же, как и в других случаях. Фильтры здесь ничего не меняют.
...
Рейтинг: 0 / 0
29.03.2019, 12:09
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793518
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarer
Код: pascal
1.
MacroByName



в каком SQL-сервере есть в запросах макросы, изменение которых не потребует unprepare/prepare запроса?
...
Рейтинг: 0 / 0
29.03.2019, 12:15
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793521
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerФильтры здесь ничего не меняют.

меняют две вещи.

1) снимают требования к скорости - человек все равно медленнее
2) делают запросы не предсказуемыми (полный комбинаторный перебор всех варинантов всех фильтров) - их нельзя захардкодить и заранее создать по компоненту на каждый из всех возможных запросов
...
Рейтинг: 0 / 0
29.03.2019, 12:17
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793522
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Ariochв каком SQL-сервере есть в запросах макросы, изменение которых не потребует unprepare/prepare запроса?
Меня удивляет постановка вопроса. Я не вижу в ней смысла. Есть ощущение, что Вы исходите из какого-то загадочного постулата, который я то ли пропустил, читая топик, то ли существует исключительно в Вашей голове.
...
Рейтинг: 0 / 0
29.03.2019, 12:19
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793524
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Arioch1) снимают требования к скорости - человек все равно медленнее
К скорости чего?

Кроме того, я не понимаю, какое отношение скорость непонятночего имеет к теме топика. Тема топика - сравнение двух подходов. А по смыслу этих подходов они сравниваются с точки зрения качества/скорости/надёжности разработки и последующего сопровождения в таком стиле.

Ariochих нельзя захардкодить и заранее создать по компоненту на каждый из всех возможных запросов
А с какой стати вообще в голову приходит такой бред?
...
Рейтинг: 0 / 0
29.03.2019, 12:23
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793580
L1G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L1G
Участник
DmSerТакже стараюсь по возможности разрабатывать классы, например TUser, TContragent, и т.п. и в их методах реализовать всю работу с бд. В этом случае сложность программы уменьшается на порядки и никакой ORM не нужно.Уточняя терминологию: считывание объектов из БД и их сохранение обратно и есть O bject- R elational M apping.
То, что в данном случае ненужно - это сторонний ORM- Framework .
...
Рейтинг: 0 / 0
29.03.2019, 14:01
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793630
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerAriochв каком SQL-сервере есть в запросах макросы, изменение которых не потребует unprepare/prepare запроса?
Меня удивляет постановка вопроса. Я не вижу в ней смысла. Есть ощущение, что Вы исходите из какого-то загадочного постулата, который я то ли пропустил, читая топик, то ли существует исключительно в Вашей голове.

Вы высказали тезис, что изменение SQL запроса с помощью StringReplace (или как угодно иначе реализованной макро-замены) не создаёт нового SQL запроса.

Но если он не создает нового запроса - значит ему не надо снова Prepare делать.
Если даже после макро-замены у нас все тот же старый SQL-запрос, то можно его запускать со старыми Prepare-данными.
...
Рейтинг: 0 / 0
29.03.2019, 14:42
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793634
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerравниваются с точки зрения качества/скорости/надёжности

не было такого ограничения
они сравнивались во всех смыслах

не навязывайте вашего личного мнения, что разрешено и запрещено сравнивать, остальным

более того, они сравнивались и конкретно по процессорному времени:
ЛюбезныйТрата времени и ресурсов на пересоздание.
Причём эту конкретную цитату я с самого начала привёл.
И именно на мою реплику про эту цитату вы отвечали.

Т.е. мы с вами говорим ИМЕННО про процессорное время.
...
Рейтинг: 0 / 0
29.03.2019, 14:46
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793635
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerAriochих нельзя захардкодить и заранее создать по компоненту на каждый из всех возможных запросов
А с какой стати вообще в голову приходит такой бред?

при том, что если в рантайме менять SQL-запросы нельзя,
softwarerМенять SQL не надо.

то это и означает, что все возможные SQL-запросы должны быть написаны ещё до рантайма
...
Рейтинг: 0 / 0
29.03.2019, 14:48
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793643
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochВы высказали тезис, что изменение SQL запроса с помощью StringReplace (или как угодно иначе реализованной макро-замены) не создаёт нового SQL запроса.
Не затруднит ли Вас показать, где я высказывал такой тезис? После чего прочитать текст и попробовать понять, что я сказал на самом деле?

Ariochне было такого ограничения
они сравнивались во всех смыслах
Безусловно. Просто в других смыслах они не дают материала для сравнения и в среднем одинаковы.

Ariochне навязывайте вашего личного мнения
Уберите ненужный пафос. Если потрудитесь понимать сказанное - не потребуется горячо возражать.

AriochТ.е. мы с вами говорим ИМЕННО про процессорное время.
По процессорному времени ответ очевиден и не стоит обсуждения - они отличаются на стоимость пересоздания/переинициализации компонент, которая незаметна на фоне общей нагрузки и укладывается в тезис про "в среднем одинаково". В случае сочетания криворукого программиста и убогого сервера БД она может быть значительно выше за счёт дополнительных Prepare, но это сочетание равно затормозит и любой другой подход, так что опять же в среднем одинаково.
...
Рейтинг: 0 / 0
29.03.2019, 14:56
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793678
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
вы сказали, что использование макро-замены в старом SQL-запросе не создаёт новый SQL-запрос

пытаться угадать, что вы могли иметь в виду ВМЕСТО того, что вы сказали - непродуктивно.

softwarerУберите ненужный пафос.
смешно слушать жалобы на пафос после 21846957

softwarerЕсли потрудитесь понимать сказанное

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

softwarerПо процессорному времени ответ очевиден и не стоит обсуждения

Для вас очевиден, а для топик-стартера не просто не очевиден, но и был НАПРЯМУЮ озвучен.
Учитесь читать и понимать, что пишут другие люди, и вам не придётся горячо возражать.
...
Рейтинг: 0 / 0
29.03.2019, 15:16
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793698
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Ariochсмешно слушать жалобы на понимание сказанного от человека, который подключился конкретно к дискуссии о скорости выполнения программы
Что ж, спасибо, мой диагноз подтвердился. Итак, посмотрим, что же было на самом деле. Вот моё подключение в "дискуссию": 21846943 . Оно отвечает на пост 21846605 , который, в свою очередь, отвечает на стартовое сообщение топика: 21846179 . Теперь очень внимательно ищем в этой дискуссии хотя бы одно упоминание о том, что это дискуссия о скорости выполнения программы. Можем раз восемь поискать для надёжности - всё равно не найдём. Как я и предположил, ты выдумал какой-то тезис у себя в голове, не потрудился хотя бы опубликовать его, и теперь несёшь чушь.

Счастливо оставаться. И это... успокоительного попей, что ли.
...
Рейтинг: 0 / 0
29.03.2019, 15:36
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793725
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerмой диагноз подтвердился

и эти люди жалуются на пафос
вы бы выбрали всё же, между трусами и крестиком

softwarerОно отвечает на пост 21846605 , который, в свою очередь, отвечает на стартовое сообщение топика: 21846179 .

Вы пропустили 21846315 Я процитирую в третий раз, если с двух раз прочитать не получилось:

"Трата времени и ресурсов на пересоздание."

Хотя... если вы восемь раз искали и не нашли, то конечно трёх цитат маловато будет.

softwarerИ это... успокоительного попей,
Доктор, что у вас с пафосом, который вы якобы так не любите? Или вы его токльо у других не любите, а у себя обожаете?

Вот если бы вы лучше вместо диагнозов по переписке объяснились бы, как же это изменение текста SQL-запроса по вашему "не меняет" SQL-запрос.

Вот это интересно бы было.
...
Рейтинг: 0 / 0
29.03.2019, 15:59
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793736
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochВы пропустили 21846315
Я его не пропускал, это другая ветка. Ты в одном посте 21846605 ответил на стартовый пост - и моя реплика относится именно к этому твоему ответу. Ниже в том же посте ты ответил на 21846315 - ну так разберись с собственными ответами и не пытайся передёргивать.

AriochВот если бы вы лучше вместо диагнозов по переписке объяснились бы, как же это изменение текста SQL-запроса по вашему "не меняет" SQL-запрос.
Прости, я не готов объяснять придуманный тобой бред, не имеющий ко мне никакого отношения.
...
Рейтинг: 0 / 0
29.03.2019, 16:14
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793918
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerМенять SQL не надо.
softwarerArioch.....по вашему "не меняет" SQL-запрос.
придуманный тобой бред, не имеющий ко мне никакого отношения.

Ах, ну да, вам срочно аккаунт взломали. Бывает, чо.
...
Рейтинг: 0 / 0
29.03.2019, 20:00
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39793929
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochАх, ну да, вам срочно аккаунт взломали. Бывает, чо.
Ещё двадцать реплик - и кто-нибудь поверит, что ты действительно не понимаешь разницы между свойством и запросом.
...
Рейтинг: 0 / 0
29.03.2019, 20:28
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794475
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
softwarerМенять SQL не надо
Код: pascal
1.
Query.MacroByName('filter').Text := Filter.CreateSQL;



Как же мне надоели твои виляния и фиглярство про softwarerдвадцать реплик

Ведь всё очень просто на самом деле.

Код: pascal
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 var macro1, macro2, sql1, sql2: string;
...
  macro1 := Filter1.CreateSQL;
  macro2 := Filter2.CreateSQL;

Query.MacroByName('filter').Text := macro1;
sql1 := Query.SQL.Text;

Query.MacroByName('filter').Text := macro2;
sql2 := Query.SQL.Text;



macro1 и macro2 - разные тексты, могут вообще не иметь ни одного общего символа.

Я утверждаю, что sql1 <> sql2.
Ты утверждаешь, что sql1 = sql2.

Всё остальное твоё словоблудие - просто чтобы замылить эту простоту.
...
Рейтинг: 0 / 0
01.04.2019, 11:13
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794502
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochТы утверждаешь, что sql1 = sql2
Плюнь в лицо тому, кто сказал тебе такую глупость. Я утверждаю вовсе не это.

AriochЯ утверждаю, что sql1 <> sql2
И по своей привычке со всего размаха садишься в лужу.
...
Рейтинг: 0 / 0
01.04.2019, 11:38
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794550
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
нет, ты утверждаешь ИМЕННО это

softwarerМенять SQL не надо

ты утверждаешь, что в результате твоих макросов SQL-запрос не изменился и пере-препарировать его не надо.
...
Рейтинг: 0 / 0
01.04.2019, 12:59
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794556
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Ariochты утверждаешь, что в результате твоих макросов SQL-запрос не изменился и пере-препарировать его не надо.
Ты можешь ещё сто раз повторить эту глупость, может быть, кто-нибудь в неё и поверит.
...
Рейтинг: 0 / 0
01.04.2019, 13:06
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794565
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
как забавно, что ты всегда убираешь собственную цитату, и надеешься что её не найдут

softwarerМенять SQL не надо
...
Рейтинг: 0 / 0
01.04.2019, 13:20
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39794566
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Ariochкак забавно, что ты всегда убираешь собственную цитату, и надеешься что её не найдут

softwarerМенять SQL не надо
Ты можешь ещё девяносто девять раз повторить эту глупость, может быть, кто-нибудь в неё и поверит.
...
Рейтинг: 0 / 0
01.04.2019, 13:21
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39795147
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Это лучше чем повторять "мы ниего не делали, мы ничего не меняли, оно само поменялось!"
...
Рейтинг: 0 / 0
02.04.2019, 13:29
| Ответить | Цитировать | Написать  
Интересует ваше мнение о двух разных подходах
    #39795151
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
AriochЭто лучше чем повторять "мы ниего не делали, мы ничего не меняли, оно само поменялось!"
Ты, кстати, так и будешь продолжать
AriochЯ утверждаю, что sql1 <> sql2.
?
...
Рейтинг: 0 / 0
02.04.2019, 13:32
| Ответить | Цитировать | Написать  
42 сообщений из 42, показаны все 2 страниц
  все  
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Интересует ваше мнение о двух разных подходах
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=58&tid=2039633]:
 0ms
get settings:
 6ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 53ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 61ms
get tp. blocked users:
 1ms
others: 193ms
total:  341ms
созд. / загр.: 341ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]