Ты точно как Tad - привёл самый простой пример.
А думаю что могут потребоваться и более сложные запросы
где не зная SQL просто запутаешься где, что и зачем надо ставить
досконально не изучив SQL .
Ещё один минус SQL надо таскать с собой.
Да просто вряд ли кто то захочет изучать SQL
для создания одной единственной базы для
собственных дисков.И которая будет забыта
через неделю - потому что её надо постоянно
заполнять .
А вообщем я же никого не заставляю.
И record здесь не панацея просто нет
у нас подобного.(визуальной БД)
На нет и суда нет.

---

Вячеслав, вообще-то это очень забавный аргумент... А что интересно мне делать, если при работе с файлом через record мне тоже понадобятся более сложные запросы Рискну ответить: посидеть пару часиков над разработкой схемы, которая этот запрос реализует. И это с учетом того, что каждый пользователь с пеленок знает алгоритмы бинарной или пузырьковой сортировки, чтобы например хотя бы отсортировать свои рекорды в алфавитном порядке. А еще мне хотелось глянуть на схему, которая скажем выдает список не повторяющихся значений из какого-то одного поля рекорда... Вот тогда мне кажется заявление о сложности использования SQL в сравнение с файлами будет не пустыми словами

Вячеслав, ответ: Создать БД, перебросить все рекорды в эту БД и совершенно забыть о головной боли при любом запросе.

Так я поэтому и написал:

Может и есть другие пути для:


StringTable сам умеет сортировать.

Вот для таких запросов и есть SQL .
А если глубоко задуматься то создать такой компонет или IC один раз и потом им пользоваться
готовые алгоритмы можно найти в инете или книгах по Делфи.

Я про простейшие базы в одном файле,где надо найти один CD ,DVD,книгу,фото.
И без всяких заморочек с её созданием и обслуживанием.

---

Ты забыл написать - изучить язык SQL для создания этих запросов
Мне кажется проще наделать примеров для работы с SQLLite со всевозожными запросами.
Глянь ка в Example один единственный пример - и ни одного комментария.

Вячеслав, я обнаруживаю противоречие в утверждениях:

и вот


т.е. если аргументы приводятся против SQL, то это обязательно сложные запросы и большие распределенные структуры данных как следствие, а если же речь о рекордах и файлах, то данные всесторонне простые и их очень мало... Просьба пояснить почему сравнение ведется в таком ключе Не кажется ли, что правильнее сравнивать одни и теже данные, получаемые разными методами Пока я вижу такую логику: ветку перерубить топором легко и уметь пользоваться им не надо, а электрической пилой бетонный столб перерезать проблематично и нужно уметь ее завести и быть знакомым с техникой безопасности... следовательно электрическая пила для распиливания веток мне не подходит.


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

------------ Дoбавленo:



Вячеслав, поскольку мне не был дан ответ на вот этот вопрос



то считаем дальнейшее упование на сложность SQL не доказанным и как следствие не правомерным

Вячеслав, есть тема "sqlite - с чем его едят". Задавай любой вопрос, получишь ответ и через месяц перестанешь бояться SQLite. Боишся ты просто.

насчет комментариев согласен (но комментариями не балуют и другие примеры ), но " один единственный пример " в Example - делает почти все и совсем не сложными запросами и командами.
Не хочешь таскать за программой "лишних" 350кб применяй OBJ - программа увеличится всего на 100кб.
Вобщем - ЗАДАВАЙ ВОПРОСЫ.
(только не начинай с вопроса: Как свести данные из десятка таблиц в одну? )

Да противоречие есть.
Смысл его сводится к одному.
К визуальности запросов.

Опять дело не в сложности ,а в визуальности.
Вот только сегодня приводили пример проги типа HiAsm от мелкософта.
там предоставляется выбор из выпадающего списка для изменения параметров.
Именно за это я радею.
Например так:
code_9740.txt
Вот что то типа такого интерфейса должно быть для
создания запросов SQL.
И дебуг должен показывать что по этому запросу будет выдано.
Как видишь к каждой функции есть русский комментарий.
При этом список колонок формируется автоматически.

---

Дело не во мне.Я могу написать на Делфи.
Я за визуальность.
видал как у мелкософта всё визуализировано.
на всё или иконки или списки.

Ну и развели вы тут дискусию. На самом деле действительно нет ничего сложного в SQL. Конечно можно сделать оболочку над SQL в HiAsm как это сделано в 1С и пишите на русском, а программа будет все ваше творчество преобразовывать в стандарт SQL, но опять же таки нужно будет изучать команды оболочки, которые, кроме как в указанной программе нигде не применяются, т.е. легче все-таки изучить SQL.

[size=-2]------ Добавлено в 02:29
Вячеслав, скачай книгу Мартина Грубера "Понимание SQL" и изучай. Уверяю нет ничего сложного

Ну как вы непоймёте дело не в SQL или записи, а в визуальности.
Ну как ты в HiAsm проверишь корректность запроса к БД SQL.

По выходу onError

А ведь был уже разговор, что SQL запросы можно тоже в виде схемы формировать. Т.е. набор компонент, которые формируют строку - правильный SQL запрос.

Именно, что разговор, и именно, что был
Был, например, и разговор про сделать любой лексер (да, впрочем - и парсер) в виде схемы -- как НКА или ДКА
Много чего было

Если вот в таком запросе я забуду что нибудь написать
Запятую,слово,скобку я всегда смогу узнать что я сделал не так.