Мда...

Тогда ещё пару вопросов:

1. Вы используете контейнер базы данных фокса?

2. Приведённый код в каком месте исполняется - просто в теле программы?

1. Контейнер базы данных фокса не использую - даже не знаю что это такое
2. Любой код исполняется в теле какой-то программы. Что имеется ввиду ?

Паша, не парься - это FPD стиль. никаких ограничений ссылочной целостности не существует. Всё упирается в корректность написания программы - если надо удить запись, то сама "кнопка удаления" и проверяет - есть ссылки или их нет. А ещё скорее это ВООБЩЕ никак не проверяется.
Повторное использование PK (в отличие от повторного использования удалённых записей) - тоже отвратительный приём. Вообще весь подобный стиль (можно было и не уточнять что ему здорово за 15 лет, и так видно откуда ноги растут) сегодня выглядит по меньшей мере убого - уже во время выхода VFP 3 он стал анахронизмом, а пытаться делать так же в C#, где даже большинство вполне нормальных для VFP приёмов и подходов "не катит"...

Igor Korolyov
- это FPD стиль...

Игорь, привет.

Да вижу я вижу.

Если человек ещё что-то не знает, то ему надо подсказать (ведь не всё мы сами знаем )

GotFocus
1. Контейнер базы данных фокса не использую - даже не знаю что это такое
2. Любой код исполняется в теле какой-то программы. Что имеется ввиду ?

1. С версии 3.0 в фоксе (1994/95г вроде) кроме свободных таблиц введено новое понятие контейнера БД и таблиц в нём.

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

Именно эти встроенные функции БД позволяют без "внешнего-программного" кода реализовать ограничения на данные, бизнес логику, итп

2. Данные во "взрослых" СУБД, да и фокс тоже не зависят от клиента (клиент может быть написан не только на фоксе, а на Акцессе например или Дельфи), другие клиенты могут и не знать о Ваших правилах с RecNO и натворить бед в данных.

PaulWist и Igor Korolyov !
Большое спасибо за Вашу просветительскую миссию. Очень много нам предоставляют
новые технологии. Я всего лишь рассказал, как всё может работать и без них(при некоторых ограничениях).
И стиль вроде не тот. А всё работает, не сыпится и занимает меньше места.

Для демонстрации того чЁ мы здесь наговорили - в аттаче пример, попробуйте в 9-ке открыть таблички Master и Detail (наша Шапка накладной с содержанием)

1. Пробуем выполнить такой код


2.


Что видим, несмотря на то, что нет нашего "пользовтельского кода" удалить из таблицы Master нельзя если есть ссылка не неё в таблице Detail, а так же внести новую запись в Detail так же нельзя если нет соответствующей записи в Master.

Об этом была речь в предыдущих постах, что используя фичи БД строится непротиворечивая модель данных.

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

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

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

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

PaulWist ! Тестик я погоняю в 21.00 . Я сейчас на работе и не Юлий Цезарь.

GotFocus
PaulWist ! Тестик я погоняю в 21.00 . Я сейчас на работе и не Юлий Цезарь.

Да хоть в 24.00 ! Нам же главное, что Вы таки решились посмотреть хоть что-то, не связанное с Вашей 15-летней технологией. Мы, кстати, тоже далеко не Цезари. Но вот что интересно, незакрывание глаз на новые технологии экономит иногда просто тучу времени, которую пришлось бы тратить на написание очередного велосипеда.




Исправлено 1 раз(а). Последнее : ssa, 14.12.10 16:46

GotFocus
Повторюсь

Цитата:

1.Упаковка таблицы(имеется ввиду PACK) самопроизвольно не происходит,
а вызывать её разумеется, нельзя.

Новые записи пишутся на место удалённых, а если таких нет, добавляются новые

Можно еще уточнить несколько вопросов:

1. Как разрешаются конфликты совместного доступа при создании новых записей?

Это когда два пользователя одновременно начали искать запись для вставки. Нашли одну и ту же запись, помеченную как удаленную, и... Вот как эта коллизия разрешается? Кто получит эту запись и что произойдет с тем пользователем, кому она не достанется?

2. Групповые вставки (APPEND FROM) вообще не используются или же они игнорируют функционал по поиску записей, помеченных как удаленные?

Цитата:

Как разрешаются конфликты совместного доступа при создании новых записей?

Перед поиском удалённой записи(поправлю-не для вставки,а для замены)вся таблица блокируется
FLOCK`ом. Разблокируется после замены. Тут конфликтов быть не может.

Цитата:

Групповые вставки (APPEND FROM)

Вы говорите Групповые вставки, а рядом пишите
команду APPEND FROM, которая добавляет записи в конец таблицы и никак не может повлиять
на записи, помеченные как удалённые.

GotFocus

Цитата:

Групповые вставки (APPEND FROM)

Вы говорите Групповые вставки, а рядом пишите команду APPEND FROM, которая добавляет записи в конец таблицы и никак не может повлиять на записи, помеченные как удалённые.

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

Если Ваша стратегия предполагает сначала поиск записей помеченных как удаленные и их использование и только если таких записей не нашли, то следует физическое создание новых записей, то APPEND FROM прямо противоречит Вашей стратегии. Она явно пропускает первый этап. Как следствие, "мусор" в таблице накапливается и Вы с ним вообще ничего не можете сделать, поскольку PACK у Вас запрещенная команда.

Отсюда следует, что если бы Вы были последовательны в своей стратегии, что и APPEND FROM следовало бы исключить из списка используемых команд, как противоречащую "генеральной линии партии"

=====================

Я попробую объяснить, чем Ваша стратегия плоха. Что в ней "не правильно".

Сначала, то, что Вы ставите в достоинство связи по Recno() - экономия места.

Ну, очевидно, что экономите Вы только и исключительно на Primary Key, поскольку Foreign Key создавать придется в любом случае. Надо же где-то хранить ссылку на код записи другой таблицы. И какова же эта экономия?

Ну, для FP2.x это 10 байт Numeric(10) или Character(10), для VFP - это 4 байта Integer. Много это или мало? Типичный справочник контрагентов содержит, как минимум, название Character(250) и адрес Character(250). И еще кучу других полей. Т.е. явно несколько сот байт. На этом фоне экономия 10 байт выглядит "крохоборством". Разумеется, рабочие таблицы, как правило, имеют несколько меньший объем, но все-равно, как минимум, около сотни байт на запись имеет почти любая таблица

Другими словами, экономия объема - незначительная.

А вот в чем недостаток?

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

Вот в этом-то и "неправильность". Вы вынуждены постоянно делать "закат солнца вручную". Писать кучу кода, который уже написан! Либо не явно, внутри Run-Time библиотек FoxPro (т.е. команд и функций, рассчитанных на существование Primary Key), либо явно в виде триггеров Referential Integrity, как в примере от PaulWist

Например, совершенно очевидно, что Вы не можете использовать команды Select-SQL для получения выборки по нескольким таблицам. Значит, Вы вынуждены писать свой собственный "движок запросов" на основе циклов перебора записей.

Другими словами, основной недостаток - это необходимость создания собственных аналогов стандартным инструментам FoxPro. Огромная избыточность кода.

Все как обычно. Стандартное правило. Недостатки структуры базы данных компенсируются избыточным программированием.

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

====================

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

Отсюда следует, что большинство инструментов, так или иначе работающих с реляционными данными также будут рассчитаны на то, что Primary Key имеет некое физическое воплощение (поле или набор полей). И никак не рассчитаны на виртуальную реализацию Primary Key.

Владимир Максимов ! Есть что ответить, но только поздно вечером. Я на работе.

GotFocus
PaulWist ! Тестик я погоняю в 21.00 . Я сейчас на работе и не Юлий Цезарь.

Ну как, тестик погоняли?

Тестик погонял. Да, ругнулась она при попытке удаления записи. Я знаю
что существует Database в дополнение к свободным таблицам.
В Database происходит непрерывное отслеживание связей между таблицами.
У меня же дозволено удалять "Накладные" без проверки к каким деталькам они
привязаны. А код в цветах выше(написанный за пол-часа), вызываемый периодически(например при выходе из программы), позволяет удалить мусор(непривязанные ни к одной накладной детальки) в справочнике.
А вот хранимые процедуры, триггеры и другие атрибуты Database когда-нибудь буду
использовать. Не подумайте, что я отказываюсь от новых технологий, просто
пока они мне не понадобились.
А вечером я овечу Владимиру Максимову, в котором с чем-то соглашусь, а с чем-то нет.

GotFocus
Тестик погонял. Да, ругнулась она при попытке удаления записи. Я знаю
что существует Database в дополнение к свободным таблицам.
В Database происходит непрерывное отслеживание связей между таблицами.
У меня же дозволено удалять "Накладные" без проверки к каким деталькам они
привязаны...

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

К данным может присоединиться ЛЮБОЙ клиент (написанный на любом языке), ... более того, этому клиенту не надо знать "а по каким правилам можно удалять, добавлять модифицировать" данные, правила-ограничения БД не дадут ввести некорректные значения, те данные сами УПРАВЛЯЮТ своей целостностью.

Собственно об этом ребята пытались сказать... выбор за Вами