Сортировка строк по их смыслу. (Алгоритм сортировки строк не по алфавиту.)

Модератор: Модераторы разделов

Аватара пользователя
Crazy
Сообщения: 862
Статус: Адепт Дзен.
ОС: Mint, Win7.

Re: Сортировка строк по их смыслу.

Сообщение Crazy »

begin2009 писал(а):
20.01.2010 21:16
Crazy писал(а):
20.01.2010 20:50
Для примера можно записать все это в таблицу, предварительно отсортировав по алфавиту строки, и хранить в файле. Дальше из файла загружать эту таблицу, а в rang выполнить алгоритм бинарного поиска по званию. Поиск займет log2(N)+1, где N число званий.

Смотрел я в эту сторону. Вообще таблица тогда будет двумерная. По одному рангу - список вариантов. И поиск в строке, затем смена строки. Вот кузяво ли будет? Тоже яйцо, но вид сбоку. То что поиск в одной строке, как сейчас пытаюсь, (а строка тоже из файла) - ничуть не лучше, признаю. Может быть кто-нибудь знает как привести строку к перечисляемому типу из строк? Вот тут-то все бы проблемы решились.

Не более 5 сравнений, а в вашем варианте в среднем 7.
Имеет смысл искать реализацию хеш-таблиц. Тогда поиск занимает одну строчку.

Desipere in loco
Спасибо сказали:
smaharbA
Сообщения: 229
ОС: Windows Vista

Re: Сортировка строк по их смыслу.

Сообщение smaharbA »

Grazy - абсолютно прав, таблица в базе/файле обязана быть и ид/вес, будет и поиск прост и сортировка
не изобретайте велосипед
Я конечно далек от мысли...(с)
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

Crazy писал(а):
20.01.2010 21:28
Не более 5 сравнений, а в вашем варианте в среднем 7.
Имеет смысл искать реализацию хеш-таблиц. Тогда поиск занимает одну строчку.

Вот смотрите, развил Вашу идею об индексировании. Пользовательский тип - запись из двух элементов ((int)(string)) Файл *.ini типизированный этого типа, загружается при старте в массив, ИМХО:много памяти не сожрет. При работе программы файл можно православно редактировать - как справочник. При сортировке пробегаемся в цикле по строковому полю и получаем по совпадении целочисленное поле. Это и есть ID. Главное, что индексировать можно не только воинские звания, но и образование и теги xml. Они будут в разных ini-файлах. И все это скармливать одной процедуре. Именно это я и хотел - общий подход, что бы использовать только одну процедуру. Длинного перебора вариантов не будет. Большинство из граждан, стоящих на учете именно "РЯДОВОЙ". Т.е. сравнение будет только 1 раз. А чем больше звание - тем меньше граждан. Правда для образования не катит: большинство "СРЕДНЕЕ ОБЩЕЕ". Хотя, кто мне мешает в файле эти пары ставить не по ID а по частоте появления. Работать (ИМХО) будет даже быстрее, чем приведенный в первом топике быдлокод. Начал реализовывать.

Всем спасибо за идеи. Но, пока бы не закрывать. Вдруг какая-нибудь трабла... и потребуются уточнения. А если нет - пусть тема сама уплывает в небытие.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

begin2009 писал(а):
19.01.2010 21:38
Т.е. программа работает с отображенными в сетке строками.

За такое даже студенты могут канделябром побить :)

begin2009 писал(а):
20.01.2010 18:56
Тут надо сортировать по званиям, а в дальнейшем - уже и по образованию. Ну, раз говнокод - случайность. Два - тенденция. А три - диагноз.

Угу, угу. Всё верно. :)

begin2009 писал(а):
21.01.2010 19:18
Вот смотрите, развил Вашу идею об индексировании. Пользовательский тип - запись из двух элементов ((int)(string))

И в итоге мы пришли к тому, что Вам советовали ещё во втором посте: "не просче в базе и добавить ид/вес ?"
Отложите пока Вашу программу, изучите основы базы данных, нормализацию и SQL.
Загруза - на недельку-две, профита - на годы.
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

DSS писал(а):
22.01.2010 04:14
За такое даже студенты могут канделябром побить :)

Ага, студенты-первокурсники (вчерашняя школота). Имея слабую надежду, что Вы не принадлежите к сей славной социальной группе, попробую все-таки объяснить. (Хотя и терзают смутные сомнения - а не кормлю ли я некий персонаж скандинавских саг.)
А Вам не приходило в голову, что программа работает локально? Что данные загружаются и затем находятся в памяти все время работы и только перед окончанием записываются? Вы куда хотите SQL засунуть? (Мог бы указать, но воздержусь). А почему бы Вам не присоветавать мне еще ODBC или, прости Господи, BDE? В памяти, понимаете - в памяти. Вы конечно уверены, что это означает динамический массив и работу с ним? Ну в крайнем случае списки, стеки и т.п.? Уверяю Вас, данные записанные в ячейках сетки тоже хранятся в памяти как динамический массив. Неожиданно? Но вот работать с данными которые записали в сетке удобнее. Ибо этот объект имеет свои методы, которыми можно пользоваться не думая о реализации размещения в памяти, сборки мусора, проверок записи и извлечения данных и т.д. А Вы были уверены, что виджеты годны только чтобы их совать на форму? Не знаю чем Вы пользуетесь, но почитайте в модулях описывающих Ваши визуальные компоненты. Увлекательное, батенька Вы мой, чтение. Увидите переменные, процедуры и функции. Может быть и мелькнет мысль как их использовать более эффективно чем просто для визуального интерфейса. Например произвести от них класс или сделать элементом в каком-нибудь объекте. И этот мой намек не относится к чему-то конкретному. В Qt имеется QTable у которого тоже много интересных возможностей. Что дает мне хранение в визуальном компоненте? Я не написав ни строчки кода реализации и не заведя ни одной переменной уже могу использовать RowCount - количество строк, Row - текущая строка, Cells - содержимое ячейки в указанных строке и столбце и т.д. Вы это все расписываете? Я не сторонник секса в противогазе, гамаке и стоя. За меня все уже расписали. В результате, в каждой процедуре я имею только локальные переменные. Глобально все держит сетка. Если это не ООП, то у нас разное ООП. И что остается для Вашего SQL? Прочитать с диска и записать на диск? Не слишком ли жирно здесь использовать SQL? Я данные храню в xml и разбираюсь с ними средствами fpc, что быстрее.
Или Вам интерфейс не понравился. Но тут уж извините. Вопросы интерфейса я буду обсуждать с инспектором по учету и бронированию военнообязанных, которая сидит через кабинет от меня, но не с Вами. И не приходило ли Вам в голову, что сетка практически на всю форму сделана по ее пожеланиям? Надо уметь пользоваться визуальными компонентами. Если бы мне понадобился другой интерфейс, то свойство сетки Visibl я бы уже как-нибудь смог бы установить в false и отображал бы данные в процедуре OnPaint на TMemo, TEdit или какой другой компонент. Если Вы хотите сделать что-нибудь действительно интересное, то не давая "вумных саветав", посмотрите-ка сами матчасть. Сетка удобна тем, что в ней хранить можно все. Даже объекты, если в ячейках хранить указатели на них.
DSS писал(а):
22.01.2010 04:14
И в итоге мы пришли к тому, что Вам советовали ещё во втором посте: "не просче в базе и добавить ид/вес ?"

А где при работе Вы увидели базу? Да еще с иде/вес? При работе существует только объект StringGrid! Перечитайте топик. Обсуждение развивалось от указания, что нужный мне метод представляет собой отображение множества строк на множество натуральных чисел, через признание хеширования наиболее подходящим средством отображения к конкретной реализации хеширования в коде. То есть вполне нормальное и продуктивное обсуждение, в результате которого я получил то, что хотел - единый метод реализованный в одной процедуре под разные задачи. Если вы этого не увидели, мне Вас жаль.
DSS писал(а):
22.01.2010 04:14
begin2009 писал(а):
20.01.2010 18:56
Ну, раз говнокод - случайность. Два - тенденция. А три - диагноз.

Угу, угу. Всё верно. :)

Это одинаково верно и о троллинге.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

begin2009 писал(а):
22.01.2010 20:15
А Вам не приходило в голову, что программа работает локально?

А что, уже появилась религия которая предписывает использовать SQL исключительно по сети?
А если я буду использовать его на 127.0.0.1 то согласно этой религии попаду в ад?
Эти вопросы риторические - можно не отвечать.

begin2009 писал(а):
22.01.2010 20:15
Что данные загружаются и затем находятся в памяти все время работы

Религия SQL сервера не запрещает ему хранить все данные в оперативной памяти.
И Вам тоже не запрещает.
Равно как и любому другому.

begin2009 писал(а):
22.01.2010 20:15
и только перед окончанием записываются? Вы куда хотите SQL засунуть? (Мог бы указать, но воздержусь). А почему бы Вам не присоветавать мне еще ODBC или, прости Господи, BDE? В памяти, понимаете - в памяти
<...>
И что остается для Вашего SQL? Прочитать с диска и записать на диск?

Вы имеете неверное представление об SQL. По-честному сказать, так SQL вообще не описывает формат хранения данных. :)
И причём здесь ODBC и BDE? Вы принципиальный противник MySQL и PostgreSQL?

begin2009 писал(а):
22.01.2010 20:15
Но вот работать с данными которые записали в сетке удобнее.

Я Вас уверяю, собрать из кучи табличек одну - это самая что ни на есть распространённая задача на SQL.
При этом собрать эту табличку можно в таких комбинациях, которые Вашей сетке и не снились.

begin2009 писал(а):
22.01.2010 20:15
А Вы были уверены, что виджеты годны только чтобы их совать на форму? Не знаю чем Вы пользуетесь, но почитайте в модулях описывающих Ваши визуальные компоненты. Увлекательное, батенька Вы мой, чтение. Увидите переменные, процедуры и функции. Может быть и мелькнет мысль как их использовать более эффективно чем просто для визуального интерфейса.

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

begin2009 писал(а):
22.01.2010 20:15
За меня все уже расписали.

Вы не поверите - в SQL за Вас расписали ЕЩЁ БОЛЬШЕ. Например, сортировки. В любых комбинациях.
И выборки. Вы ещё не думали, какие Вам придётся дописать алгоритмы, чтобы отобразить в Вашей сетке "только рядовые и матросы" или "только младшие офицеры"?
Используя базу данных, Ваша задача - только следуя нескольким несложным правилам спроектировать её структуру.

begin2009 писал(а):
22.01.2010 20:15
Или Вам интерфейс не понравился.

"Глупости говорите..."(с)профессор
Разговор идёт про данные - про них и говорим.

begin2009 писал(а):
22.01.2010 20:15
А где при работе Вы увидели базу? Да еще с иде/вес? При работе существует только объект StringGrid! Перечитайте топик. Обсуждение развивалось от указания, что нужный мне метод представляет собой отображение множества строк на множество натуральных чисел, через признание хеширования наиболее подходящим средством отображения к конкретной реализации хеширования в коде. То есть вполне нормальное и продуктивное обсуждение, в результате которого я получил то, что хотел - единый метод реализованный в одной процедуре под разные задачи. Если вы этого не увидели, мне Вас жаль.

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

* первый раз промахнулся в Tab + Space вместо й + space.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Сортировка строк по их смыслу.

Сообщение drBatty »

DSS писал(а):
22.01.2010 21:04
По ходу обсуждения я увидел, что Вы просто не знаете баз данных. Возможно ошибся, не спорю. Но слишком уж ярко.

на самом деле, данная задача конечно подошла-бы для SQL, если-бы не объём - 20 значений, 200 строчек, 2 столбца... 2 таблицы... Это как палить из пушки по воробьям. Хотя конечно если пушка УЖЕ есть, готовая, заряженная, то можно. Только наводить сложно и долго, имхо рогатка удобнее. Т.ч. вы зря доказываете преимущества БД.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

Вообще про религию "свидетели SQL" узнал только сегодня. Если Ваша религия и не запрещает хранить данные в памяти, то уж не использующим SQL - анафема. Зачем мне это? Я решаю задачи в программе более простым и прозрачным кодом. А Вы всегда из пушки по воробьям? Вы можете внятно объяснить зачем мне здесь использовать SQL? Потому что ТРУЪ? Мне ничего не надо собирать. После расположения данных в ячейках все абсолютно тривиально. Споткнулся на сабже. Это - первая трудность, уже решенная. Проблема с использованием сетки для хранения данных? - она для этого и предназначена.

Все фильтрации и поиски решаются очень просто. И что характерно - первый вариант программы на скрине использовал именно базы данных. Сначала dBase, потом mdb. И везде были бесконечные SELECT ... FROM ... А сетку использовал связанную с базой. Только для отображения данных. А потом мелькнула мысль: а на сетке данные можно хранить тоже. Мне что запросы читаемости добавляют в коде или скорости? Теперь данные в xml, обработка в сетке. То что задача - это типовое применение (я бы вообще сказал - прямо учебный пример) базы данных - не спорю. Ее вообще можно сделать даже в Access. Только мне этого не надо. Почему я должен свою программу привязывать к чему-то. Все сделано самым простым способом. Сетка - готовый инструмент. Если мне понадобится - сделаю базу из связанных локальных таблиц, понадобится - одним файлом. Но сейчас необходимости в этом не вижу.

drBatty писал(а):
22.01.2010 22:18
DSS писал(а):
22.01.2010 21:04
По ходу обсуждения я увидел, что Вы просто не знаете баз данных. Возможно ошибся, не спорю. Но слишком уж ярко.

на самом деле, данная задача конечно подошла-бы для SQL, если-бы не объём - 20 значений, 200 строчек, 2 столбца... 2 таблицы... Это как палить из пушки по воробьям. Хотя конечно если пушка УЖЕ есть, готовая, заряженная, то можно. Только наводить сложно и долго, имхо рогатка удобнее. Т.ч. вы зря доказываете преимущества БД.

Пока писал увидел Ваш ответ. Спасибо. Так внятно сформулировать мне не удалось.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

drBatty писал(а):
22.01.2010 22:18
на самом деле, данная задача конечно подошла-бы для SQL, если-бы не объём - 20 значений, 200 строчек, 2 столбца... 2 таблицы...

Таблиц там явно не две.
Минимум 5: военно-учетная специальность, воинское звание, группа учета, образование, сводная. Учитывая размер и положение бегунка горизонтальной прокрутки - раза в 3 больше.
А если уж совсем грамотно, то фамилия, имя, отчество - тоже отдельные таблицы ;)
И это сейчас. А через годик, как обычно, захочется ещё и ещё.

drBatty писал(а):
22.01.2010 22:18
Это как палить из пушки по воробьям. Хотя конечно если пушка УЖЕ есть, готовая, заряженная, то можно. Только наводить сложно и долго, имхо рогатка удобнее.

Да вон, на складе валяются современные пушки, влезают в карман, наводятся сами в три раза быстрее рогаток, мощность - с рогатками не сравнима даже близко - возьмите, сколько Вам надо:
http://ru.wikipedia.org/wiki/HSQLDB
http://ru.wikipedia.org/wiki/SQLite

begin2009 писал(а):
22.01.2010 22:26
Вы можете внятно объяснить зачем мне здесь использовать SQL? Потому что ТРУЪ?

Нет, потому что контроль целостности данных, простота сортировки, выборки (в том числе сложных). Использование стандартных механизмов вместо своих.
Почитаем, что Вы пишете: "Пользовательский тип - запись из двух элементов ((int)(string)) Файл *.ini типизированный этого типа, загружается при старте в массив, При работе программы файл можно православно редактировать - как справочник. При сортировке пробегаемся в цикле по строковому полю и получаем по совпадении целочисленное поле. Это и есть ID. Главное, что индексировать можно не только воинские звания, но и образование и теги xml. Они будут в разных ini-файлах."
Вам не кажется, что Вы, фактически, свою СУБД на ini файлах ваяете? ;)

begin2009 писал(а):
22.01.2010 22:26
Ее вообще можно сделать даже в Access.

OOo Base. ;)

В свете изложенного в Вашем последнем посте, продолжать дискуссию не вижу никакого смысла. С SQL, как вижу, Вы всё-таки знакомы. Дальше - Ваше дело. Удачи.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Сортировка строк по их смыслу.

Сообщение drBatty »

DSS писал(а):
23.01.2010 08:58
Минимум 5: военно-учетная специальность, воинское звание, группа учета, образование, сводная. Учитывая размер и положение бегунка горизонтальной прокрутки - раза в 3 больше.
А если уж совсем грамотно, то фамилия, имя, отчество - тоже отдельные таблицы

??? это какая-то странная религия. хранить имя и фамилию в разных таблицах? поясните: ЗАЧЕМ?
DSS писал(а):
23.01.2010 08:58
А через годик, как обычно, захочется ещё и ещё.

ой, бросьте... была часть на 300 солдат и офицеров, через год станет на 30 000?! Да её скорее расформируют. Армия это такая закостенелая вещь...
DSS писал(а):
23.01.2010 08:58
Да вон, на складе валяются современные пушки, влезают в карман, наводятся сами в три раза быстрее рогаток, мощность - с рогатками не сравнима даже близко - возьмите, сколько Вам надо:

зачем? дорого они стОят, ваши карманные пушки.
DSS писал(а):
23.01.2010 08:58
Вам не кажется, что Вы, фактически, свою СУБД на ini файлах ваяете?

так и есть. однако специализированная СУБД работает быстрее и надёжнее чем универсальная + набор костылей и подпорок. и проще в обслуживании (ну например не нужно будет разбираться с кодировками, ну какая может быть в Армии кодировка?, не нужно будет держать 95% мёртвого кода "для поддержки сложных запросов", ну зачем это надо в армии?). К вашим карманным пушкам нужен специально обученный стрелок + высокотехнологичные боеприпасы. Рогатка может стрелять всякой фигнёй, и использовать её может любой пацан.
DSS писал(а):
23.01.2010 08:58
В свете изложенного в Вашем последнем посте, продолжать дискуссию не вижу никакого смысла.

угу. а вообще begin2009 лучше знает, что ему использовать. может у него чип ОЭВМ внутри "высокотехнологичной пушки" в проекте :)
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
smaharbA
Сообщения: 229
ОС: Windows Vista

Re: Сортировка строк по их смыслу.

Сообщение smaharbA »

а потом будет ветка - "Как перевести имеющийся код в скуль-запросы"
Я конечно далек от мысли...(с)
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

Ну слава Богу, бессмысленная дискуссия кончилась. Объясню преимущество своего подхода в данном конкретном случае.
1) Программа будет работать без установки. С флешки. Мне не надо знать что установлено на каком-то компьютере. Если есть любой линукс и любая ДЕ, программа точно пойдет.
2) Из-за отсутствия глобальных переменных - возможность накосипорить в программе исчезает напрочь. Сами процедуры обработки событий занимают несколько строчек. К примеру переход к следующей записи - 2 строки. Быстрый поиск по фамилии 12 строк (включая begin - end).
3) Сетка работает в связке с xml. Если через год понадобится внести, к примеру, "размер противогаза", то я добавлю 1 столбец в сетке и новые теги в xml. Код при этом практически не изменится. Причем новый бинарник будет работать со старым файлом данных и наоборот.
4) Выбор текущей строки осуществляется как по кнопкам выше-ниже, так и кликом мыши. Вы думаете я что-то писал? Это свойство сетки - строка на которую кликнула мышь - текущая! Прокрутка колесиком так же не реализовывалась. Это тоже свойство таблицы.
5) Сетка визуальный элемент, значит компьютер ее постоянно сканирует для перерисовки. Любое действие поставленое в процедуру DrawCell (отрисовает ячейки) будет совершено при отрисовке. Как визуально - текущая строка имеет другой цвет, так и можно произвести любую выборку или проверку. Только условие в эту процедуру.

Я далек от экстремистского лозунга: "Пролетарий - на сетку!" Делайте как Вам удобнее. Просто совет, если встретится что-нибудь не глобальное - попробуйте таким путем. Вот когда будете видеть два пути, тогда и сможете рассуждать: что же лучше в данном конкретном случае.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

drBatty писал(а):
23.01.2010 09:47
??? это какая-то странная религия. хранить имя и фамилию в разных таблицах? поясните: ЗАЧЕМ?

А затем. Во-первых, идеологически верно (та самая нормализация, ага). Во-вторых, сразу есть информация о том, какие фамилии у нас имеются. В-третьих, различные типовые задачм, как то: "отобрать всех Ивановых", "отобрать всех на букву И", "отсортировать", "подсказка при наборе" выполняется в разы проще и быстрее.

drBatty писал(а):
23.01.2010 09:47
ой, бросьте... была часть на 300 солдат и офицеров, через год станет на 30 000?! Да её скорее расформируют. Армия это такая закостенелая вещь...

Насколько я понимаю, глубокоуважаемый begin2009 пишет программу для своей сельской администрации, а не для Армии. Т.е. контингент, подлежащий учёту, может изменяться.

drBatty писал(а):
23.01.2010 09:47
угу. а вообще begin2009 лучше знает, что ему использовать

Именно поэтому, после того, как стало понятно, что begin2009 с базами данных знаком, я и решил прекратить дискуссию на эту тему.
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

DSS писал(а):
23.01.2010 12:06
drBatty писал(а):
23.01.2010 09:47
??? это какая-то странная религия. хранить имя и фамилию в разных таблицах? поясните: ЗАЧЕМ?

А затем. Во-первых, идеологически верно (та самая нормализация, ага). Во-вторых, сразу есть информация о том, какие фамилии у нас имеются. В-третьих, различные типовые задачм, как то: "отобрать всех Ивановых", "отобрать всех на букву И", "отсортировать", "подсказка при наборе" выполняется в разы проще и быстрее.

drBatty писал(а):
23.01.2010 09:47
ой, бросьте... была часть на 300 солдат и офицеров, через год станет на 30 000?! Да её скорее расформируют. Армия это такая закостенелая вещь...

Насколько я понимаю, глубокоуважаемый begin2009 пишет программу для своей сельской администрации, а не для Армии. Т.е. контингент, подлежащий учёту, может изменяться.

drBatty писал(а):
23.01.2010 09:47
угу. а вообще begin2009 лучше знает, что ему использовать

Именно поэтому, после того, как стало понятно, что begin2009 с базами данных знаком, я и решил прекратить дискуссию на эту тему.

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

Код: Выделить всё

procedure TMainForm.Edit1Change(Sender: TObject);
var i: integer;
begin
 for i:=1 to MainGrid.RowCount-1 do
 begin
  if WideUpperCase(Edit1.Text)=WideUpperCase(copy(MainGrid.Cells[1,i],1,length(Edit1.Text)))
      then begin
           MainGrid.Row:=i;
           MainGrid.Refresh;
           exit;
           end;
 end;
end;
Ну элементарный код же!
А по изменению контингента? Это горе. Население убывает по 3 - 3.5 % в год. Какое же увеличение. Рад бы в рай да грехи не пускают. Но вообще как-то задался целью проверить - сколько данных может хранить сетка пока не загнется. 128 000 данных (ну тестовых, всякая ересь) - обрабатывала и не только не падала, но и не тормозила заметно глазу.

ЗЫ А вообще таблица там одна - сетка, хотя можно указателями соорганизовать взаимодействие разных сеток (таблиц). Тогда получим взаимосвязанные таблицы.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Сортировка строк по их смыслу.

Сообщение drBatty »

DSS писал(а):
23.01.2010 12:06
А затем. Во-первых, идеологически верно (та самая нормализация, ага). Во-вторых, сразу есть информация о том, какие фамилии у нас имеются. В-третьих, различные типовые задачм, как то: "отобрать всех Ивановых", "отобрать всех на букву И", "отсортировать", "подсказка при наборе" выполняется в разы проще и быстрее.

свойство "Иванов Иван Иванович" принадлежит одному объекту. "все Петровны" не имеют НИЧЕГО общего, окромя отчества. И "Ивановы" - тоже (если отбросить родственные связи).
Зачем мешать в одну кучу
Иванов Пётр Анисимович
Белкина Ирина Васильевна
Петров Пётр Игнатьевич
? что в них общего?
все на И?
смысл?

begin2009 писал(а):
23.01.2010 12:32
Население убывает по 3 - 3.5 % в год. Какое же увеличение.

может "где-то в России" ваша программа будет обрабатывать не посёлок, а всю область ;)
но всё равно - нет смысла в БД ИМХО
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

drBatty писал(а):
23.01.2010 12:57
Иванов Пётр Анисимович
Белкина Ирина Васильевна
Петров Пётр Игнатьевич

Ну здесь этого не надо, а вот у меня телефонный справочник по району, так там таки да. Что бы не вводил: фамилию, адрес, номер (часть слова) - выходит вся запись. Т.е. справочник становится универсальным для использования. А в данном случае хранить в разных столбцах имело бы смысл если бы военкомат задавал задачу типа - сколько Александров имеют звание сержант. Или сколько Николаевичей родилось в период 1970-1980гг. Даже имея опыт общения с вояками, пребываю в уверенности что им такие фантазии и в голову не придут!
drBatty писал(а):
23.01.2010 12:57
может "где-то в России" ваша программа будет обрабатывать не посёлок, а всю область ;)

Не возражаю (программа под линукс и это какбэ намекает)! А вообще я уже говорил, что для интереса тестил - сколько обработает. Поленился увеличивать. Остановился на 128тыс. Надо было поставить мульён и посмотреть. Работает - нет проблем. (Население области меньше 700 000).

А вообще мне даже странно, что этот подход вызвал такую бурную реакцию у кое-кого. Стал вспоминать: свое ли ноу-хау или где-то когда-то подсмотрел. Поднял литературу. Оказалось нет, не мое. Подсмотрел в книге Фленова еще когда был офтопик и я использовал дельфи, да просто забыл уже откуда. Так и тяну не помня автора.
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
mix1m
Сообщения: 187
ОС: openSUSE 11.2

Re: Сортировка строк по их смыслу.

Сообщение mix1m »

begin2009 писал(а):
23.01.2010 14:17
А вообще мне даже странно, что этот подход вызвал такую бурную реакцию у кое-кого.

дык хардкод и пр. "не архитектурно гибкие" решения:))
зы. я тоже за базу данных. Реальную или импровизированную(xml и т.д., если уже совсем не хочеться разносить систему на разные уровни)
А если уж совсем грамотно, то фамилия, имя, отчество - тоже отдельные таблицы

это жесть) даже на вики написано - "не лезьте в нормальные формы выше третьей":) не говоря уже о том что фамилии и имена даже к нормализации никаким боком нельзя прикрутить
Попытка - первый шаг к провалу (с) Гомер
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

mix1m писал(а):
23.01.2010 20:25
зы. я тоже за базу данных. Реальную или импровизированную(xml и т.д., если уже совсем не хочеться разносить систему на разные уровни)

Дык по гражданскому кодексу - базой является мой xml на диске. А что я чмурю это ее система управления. По ГК вообще-то в понятие БД не входит. Или я ошибаюсь?
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

begin2009 писал(а):
23.01.2010 12:32
Ну элементарный код же!

На мой взгляд select family from family_table where family like string, где string = набранные буквы+% намного элементарнее :)

drBatty писал(а):
23.01.2010 12:57
свойство "Иванов Иван Иванович" принадлежит одному объекту

Т.е. в БД Вы создадите ТОЛЬКО ОДИН атрибут для хранения полного ФИО?

mix1m писал(а):
23.01.2010 20:25
это жесть)

Жесть, не жесть, а очень удобно. :)
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Сортировка строк по их смыслу.

Сообщение drBatty »

DSS писал(а):
24.01.2010 10:28
свойство "Иванов Иван Иванович" принадлежит одному объекту


Т.е. в БД Вы создадите ТОЛЬКО ОДИН атрибут для хранения полного ФИО?

э?
я не знаю. либо один столбец, либо три столбца. но никак не 3 таблицы!
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
begin2009
Сообщения: 349
Статус: Ламер со стажем
ОС: без глюков

Re: Сортировка строк по их смыслу.

Сообщение begin2009 »

DSS писал(а):
24.01.2010 10:28
На мой взгляд select family from family_table where family like string, где string = набранные буквы+% намного элементарнее :)

Экий Вы лукавый. Вашему коду соответствует из моего WideUpperCase(Edit1.Text)=WideUpperCase(copy(MainGrid.Cells[1,i],1,length(Edit1.
Text))). А все остальное только для того чтобы выбранная строка стала текущей. К тому же есть два отличия. Во первых независимо от регистра.("ИвАнОв" тоже допустимо) А во вторых происходит динамически. Обработка события OnChange. Т.е. само добавление буквы создает событие. На практике это выглядит достаточно элегантно. Вводим буквы - строка автоматически смещается к первому наиболее близкому варианту. Обычно для нераспространенных фамилий достаточно нескольких букв. Ну а по распространенным чаще всего фамилия+1или2 буквы имени.
DSS писал(а):
24.01.2010 10:28
Т.е. в БД Вы создадите ТОЛЬКО ОДИН атрибут для хранения полного ФИО?

В данном случае да. У вояк во всех документах/отчетах фигурирует "ФИО", поэтому детализировать излишне. А вот для похозяйственного учета, действительно было заведено 3 атрибута для члена хозяйства. Правда для него же в категории "Глава хозяйства" фамилия+имя+отчество объединялись из него же но в категории "член семьи". Так было удобнее сортировать по главам хозяйств. Жгунов около 100, Жгунов Викторов 3, а Жгун Виктор Николаевич уникален. (Правда Жгунов Викторов Сергеевичей 2, но из двух результатов поиска один как-то можно выбрать и мышкой).
DSS писал(а):
24.01.2010 10:28
Жесть, не жесть, а очень удобно. :)

Тут дело в поставленной задаче. А вот если заносить все имена/фамилии/отчества в справочник и выбирать оттуда, вот это действительно жесть! У Паруса так для многих атрибутов сделано. Работать с этим подельем жесть тоже!
(drBatty) писал(а):я не знаю. либо один столбец, либо три столбца. но никак не 3 таблицы!
Про это и говорил. А у кодеров из паруса свое ИМХО (здесь в смысле "имею мнение, хрен оспоришь")
Пессимист видит темный туннель, оптимист видит свет в конце туннеля, реалист видит свет, туннель и поезд.
И только машинист видит этих трех идиотов, сидящих на рельсах.
Спасибо сказали:
Аватара пользователя
korvin
Сообщения: 39
ОС: >_<

Re: Сортировка строк по их смыслу.

Сообщение korvin »

DSS писал(а):
22.01.2010 21:04
Вы принципиальный противник MySQL и PostgreSQL?

да тут пожалуй и sqlite достаточно будет
(© '(define LISP (такой язык-программирования (состоящий-из смайликов (чуть более) (чем целиком)))) lurkmore)
Спасибо сказали:
mix1m
Сообщения: 187
ОС: openSUSE 11.2

Re: Сортировка строк по их смыслу.

Сообщение mix1m »

DSS писал(а):
24.01.2010 10:28
mix1m писал(а):
23.01.2010 20:25
это жесть)

Жесть, не жесть, а очень удобно. :)

не удобно, а экономит место. Да и то только на десятках милионов записей. Во всех остальных случаях просто гемор. Способ доступа к данным с точки зрения базы останется тот же либо ухудшится. Для быстрого поиска по фамилии вам придется индексировать всю табичку уникальных фамилий с суррогатным ключем + внешний ключ в табице где вы храните персон. Не удобно это еще и тем, что фактически, объекта "Фамилия" у вас нету. Если вы удалите фамилию "Иванов" из таблицы фамилий - что будет на месте id этой фамилии в табце персон? null? каскадное удаление? в общем жесть;)
Попытка - первый шаг к провалу (с) Гомер
Спасибо сказали:
Аватара пользователя
korvin
Сообщения: 39
ОС: >_<

Re: Сортировка строк по их смыслу.

Сообщение korvin »

begin2009 писал(а):
24.01.2010 11:00
Тут дело в поставленной задаче. А вот если заносить все имена/фамилии/отчества в справочник и выбирать оттуда, вот это действительно жесть! У Паруса так для многих атрибутов сделано. Работать с этим подельем жесть тоже!

это можно делать автоматически, незаметно для пользователя, если в Парусе так не сделали, то это не значит, что так нельзя делать =)
(© '(define LISP (такой язык-программирования (состоящий-из смайликов (чуть более) (чем целиком)))) lurkmore)
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

drBatty писал(а):
24.01.2010 10:44
э?
я не знаю. либо один столбец, либо три столбца. но никак не 3 таблицы!

Один столбец - отличное решение. Начиная от запросов с конструкциями вида %string% и заканчивая сокращением до "Фамилия И.О." :)

mix1m писал(а):
24.01.2010 11:19
Не удобно это еще и тем, что фактически, объекта "Фамилия" у вас нету. Если вы удалите фамилию "Иванов" из таблицы фамилий - что будет на месте id этой фамилии в табце персон? null? каскадное удаление? в общем жесть;)

Хорошо. Рассмотрим базу для торговли. Удаляем строку "Веник" из таблицы товаров. Что должно произойти? В таблице остатков по складам, где он у нас числился, например.
Вот ровно то же самое произойдёт при удалении фамилии "Иванов" из справочника фамилий. ;)
Спасибо сказали:
mix1m
Сообщения: 187
ОС: openSUSE 11.2

Re: Сортировка строк по их смыслу.

Сообщение mix1m »

DSS писал(а):
24.01.2010 15:40
mix1m писал(а):
24.01.2010 11:19
Не удобно это еще и тем, что фактически, объекта "Фамилия" у вас нету. Если вы удалите фамилию "Иванов" из таблицы фамилий - что будет на месте id этой фамилии в табце персон? null? каскадное удаление? в общем жесть;)

Хорошо. Рассмотрим базу для торговли. Удаляем строку "Веник" из таблицы товаров. Что должно произойти? В таблице остатков по складам, где он у нас числился, например.

пример притянут за уши и к рассматриваемому вопросу достаточно параллелен...
навскидку - для базы торговли логичным будет оставлять поле пустым, либо давайте дефинишены таблиц для полного анализа)
Для персон, фамилий и т.д. такое поведение неприемлемо. Функционально сущности "Товары", "Склады", "Остатки" выбраны верно и совсем не похожи на "Персоны","Фамилии","..". У товара нет атрибута "остаток на таком-то складе", в то время как у человека есть четкий атрибут - "фамилия".
Попытка - первый шаг к провалу (с) Гомер
Спасибо сказали:
smaharbA
Сообщения: 229
ОС: Windows Vista

Re: Сортировка строк по их смыслу.

Сообщение smaharbA »

о ссылочной целостности видать слышали только "тупые адинеснеги", всем остальным до....
Я конечно далек от мысли...(с)
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

mix1m писал(а):
24.01.2010 16:03
пример притянут за уши и к рассматриваемому вопросу достаточно параллелен...

Абсолютно симметричная ситуация.

mix1m писал(а):
24.01.2010 16:03
навскидку - для базы торговли логичным будет оставлять поле пустым, либо давайте дефинишены таблиц для полного анализа)

Полные определения таблиц не нужны. И так всё ясно.
Удалили товар из таблицы товаров, в складах получили неопределённый товар на всех складах.
Дополнительно грохнули товар "Тазик" - и в этой базе уже никто никогда не разберётся ;)

smaharbA писал(а):
24.01.2010 19:06
о ссылочной целостности видать слышали только "тупые адинеснеги", всем остальным до....

На то они и тупые адинэсниги. Им тупая адинэска не даёт удалять без этого контроля :)
Спасибо сказали:
mix1m
Сообщения: 187
ОС: openSUSE 11.2

Re: Сортировка строк по их смыслу.

Сообщение mix1m »

DSS писал(а):
24.01.2010 19:49
Удалили товар из таблицы товаров, в складах получили неопределённый товар на всех складах.

и вы считаете это нормальная ситуация? :laugh:
DSS писал(а):
24.01.2010 19:49
Абсолютно симметричная ситуация

дискусс зашел в глухой тупик...
(smaharbA) писал(а):о ссылочной целостности видать слышали только "тупые адинеснеги", всем остальным до....

претензия "ниочем". Вас кто-то обидел вместе с 1С?
К тому же не все субд полноценно поддерживают работу с констрейнтами.
Попытка - первый шаг к провалу (с) Гомер
Спасибо сказали:
DSS
Сообщения: 390

Re: Сортировка строк по их смыслу.

Сообщение DSS »

mix1m писал(а):
25.01.2010 14:22
DSS писал(а):
24.01.2010 19:49
Удалили товар из таблицы товаров, в складах получили неопределённый товар на всех складах.

и вы считаете это нормальная ситуация? :laugh:

Вообще-то я так понимаю, что это Вы считаете, что это нормальная ситуация.
Иначе зачем бы Вы писали это: "навскидку - для базы торговли логичным будет оставлять поле пустым" ?
Спасибо сказали: