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

С этим утверждением согласен, только до слов - "что-то где-то", для этого существует механизм ограничений (PK/FK/CK, CHECK, TRIGGER), если наши подправления нарушают эти ограничения, то вот это "что-то где-то" не пройдёт, а если пройдёт, то это сам понимаешь на чьи руки надо пенять. (не имею ввиду уважаемое собрание)

ВладимирМОтбрасывание ведущих пробелов в момент записи информации в таблицу (если этого не делать, то как раз и нужен индекс по AllTrim()) - это всего-лишь один из множества разнообразных контролей процесса записи информации.

Тогда обьясни как ты будешь отбрасывать ведущие пробелы для записей модифицируемых сторонним софтом на все CHAR поля писать RULE


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

Надо ли это понимать, что НЕЛЬЗЯ использовать данные созданные в наших программах другим софтом, потому что другая прога не знает о наших допущениях (это мне напоминает фразу - если программа работает не так как надо, то отразим это в документации)

ВладимирМЕсть еще ряд проблем такого "стороннего" вмешательства. В общем случае, это не проблема автора программы, а проблема того, кто влез в базу данных используя сторонние программы.

У меня Дежа вю, какое-то на цитаты.

Ошибок не бывает вообще, есть ситуации для которых программист не предусмотрел проверки (с) Лес Пинтер

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

Вот про кривизну контроля целостности по подробнее, если можно пример.

ВладимирМ

Ну вообщем сам привожу примеры для разных случаев.


В любом случае есть ещё проблемы с SELECT-SQL, не зависимо от выражения индекса (PADR/ALLTRIM) в WHERE условии надо повторить этот синтаксис.

Ладно, оставим этот разговор, а то он у нас случается раз в полгода.

Хотя если у тебя есть пояснения готов выслушать с большим вниманием. :))

ВладимирМ PaulWist

С этим утверждением согласен, только до слов - "что-то где-то", для этого существует механизм ограничений (PK/FK/CK, CHECK, TRIGGER), если наши подправления нарушают эти ограничения, то вот это "что-то где-то" не пройдёт, а если пройдёт, то это сам понимаешь на чьи руки надо пенять. (не имею ввиду уважаемое собрание)

Это утверждение предполагает, что ВСЯ бизнеслогика, в том, что касается целостности базы данных, вынесена на уровень триггеров. Как минимум, в хранимые процедуры. В идеале так и должно быть. Но, как правило, от этого правила отступают. Слишком громоздко получается...

Я бы разделил бизнес логику на две составляющих

1. Поддержание ссылочной целостности (PK/FK), ограничений (CK/RULE)
2. Собственно занесение/модификация данных

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

Теперь по модификации данных - согласен, что в большинстве случаев мы в коде приложения получаем PK для Мастер-таблицы и ручками его прописываем в Детали-таблицу, но это идеологически не правильно и я прекрасно понимаю, что такие наши действия - это наследие FPD.

Поэтому если отбросить п.2, то ничего сложного для поддержания БД мне кажется нет.

ВладимирМНу, это-то просто...

1) FORMAT="T" - в свойствах поля.

Поскольку эта настройка может быть перекрыта в формах, то добавляю безусловный контроль

2) RULE-уровня записи

Принято.

ВладимирМНельзя (по крайней мере очень не желательно) модифицировать данные при помощи другого софта. А использовать (в смысле на просмотр), конечно можно.

Конечно имелось в виду, модифицировать. Даже не знаю, что сказать.

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

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

ВладимирМТы рассмотрел только вопрос ведущих пробелов. А ведь вариантов модификации базы данных, когда это делается напрямую, минуя прогу, огромное количество. Далеко не все возможные проблемы можно решить через правила и тригера

ВладимирМИндекс по AllTrim() - это предположение, что данные не корректны! Их нельзя использовать напрямую. Без предварительного преобразования. Тогда встает вопрос почему только AllTrim().

Отвечу твоей же цитатой, которую мы приняли

ВладимирМС другой стороны, наличие ведущих пробелов ( если это не обусловлено спецификой данных )

Те, другими словами нас не интересуют пробелы, а интересуют значащие символы отличные от пробелов.

Владимир, напомню с чего началось

ВладимирМНе совсем. Такой индекс эквивалентен отбрасыванию ведущих пробелов.

Т.е. конструкция допустима, но FoxPro сам, автоматически, после отсечения ведущих и концевых пробелов добавит концевые пробелы в выражение ключа до количества символов в поле sh.

Идеологически, да, неверно .

Из этого следует, что использование ALLTRIM() идеологически неверно, а
PADR() определялось как правильное решение (таких слов от тебя не было написано, но и о том, что PADR() или др ф-ию не хорошо использовать тоже не прозвучало ).

ВладимирМЕсли для работы с данными требуется их преобразование в обязательном порядке, то возникает серьезное сомнение в достоверности самих данных.

Ну, думаю ты здесь малёк переборщил - данные они и есть данные, независимо надо их преобразовывать или нет - это как обьективная реальность данная нам в ощущения. А то что мы их можем преобразовать на этапе модификации или на этапе использования - это зависит, как правило от задачи, а не от данных.

ВладимирМКлючевой момент - это именно разбор структуры данных. Сам понимаешь, что просто так взять и вставить куда-то данные нельзя. Надо проследить всю цепочку взаимодействий и убедиться, что твоя модификация не повредит целостности базы данных.

Т.е. ты сам предполагаешь, что не весь контроль ссылочной целостности вынесен в триггера и правила. Что-то, где-то не учли (специально или случайно - другой вопрос)

Да, конечно, при разнородных источниках данных просто невозможно используя внутренние механизмы Fox-a поддерживать ссылочную целостность, для этого приходится использовать либо собственное творчество реализованное в триггерах, либо софт стороннего производителя, но это не значит, что этого не надо делать. Да это трудоёмко и на первый взгляд не очевидно, но в дальнейшем решает массу проблем.

ВладимирМ PaulWistТаким образом мы убиваем несколько зайцев и главный из них - это создание корпоративной БД, а не набор проектов реализующий ту или иную функциональность.

Теоретически. Практически, такая конструкция долго не живет. Это кончается либо приобритением, либо написанием единой ERP-системы. Слишком тяжело сопровождать систему слепленную из массы разнородных модулей.

У меня мнение другое, с точностью до наоборот. Теоретически, хорошо бы иметь одну систему, а практически это не реально, первый аргумент - это мнение генерала, который говорит - "я и так затратил кучу денег, а ты мне предлагаешь опять раскошелиться", а второй аргумент - ну купили ERP - систему, через какое-то время возникает необходимость в CRM системе, причем разработка её под ERP составит круглую сумму, а покупка готового решения даже с доделками/настройками обойдется 1000-2000$ на рабочее место. Через какое-то время выяснится, что ещё что-то нужно, и сам понимаешь колробочный софт будет на порядок дешевле разработки.

Где-то года два назад, я у себя в конторе пытался подсчитать - какое кол-во прикладного софта используется - когда дошел до цифры в 80 программ, бросил.
Это я к чему ни одна система не может обеспечит всего функционала хозяйственной деятельности предприятия, да ещё если оно развивается.

Ну давай вернемся к нашим баранам, а то действительно понесло в философию.

ВладимирМ В исходном запросе конструкция с AllTrim() явно использовалась для связки PK-FK. Это идеолгоически неверно при любом раскладе. PK вообще не должен никак преобразовываться. На то он и PK.

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

ВладимирМИндекс по PK - это всего-лишь инструмент ускорения поиска нужного значения.

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

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

Давай вернемся к FORMAT = "T"

Что-то я засомневался в таком подходе отсечения ведущих пробелов.

Проверим.


Пожалуй, только RULE остается.