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

PaulWist

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

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

Не так. Разница в том, должен ли программист сам писать код или он уже написан разработчиками СУБД. Достаточно просто использовать нечто готовое. Механизм запуска этого кода - уже другой вопрос.

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

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

Например, в ряде коммерческих приложений стараются сделать прямо противоположное. Убрать вообще всю логику из базы данных и используют их как обычное хранилище. Смысл в том, что в этом случае в качестве хранилища данных можно использовать практически любую СУБД. Как следствие, потенциальный клиент не привязан к какой-то конкретной СУБД и можно купить продукт дешевле, если какая-то СУБД у клиента уже есть.

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

Это к тому, что понятие "правильная" БД - сильно "растяжимое".

Владимир Максимов

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

Не так. Разница в том, должен ли программист сам писать код или он уже написан разработчиками СУБД. Достаточно просто использовать нечто готовое. Механизм запуска этого кода - уже другой вопрос.

Согласен, что "встренное" легче, не всегда правда лучше.

Не согласен в другом, (речь не идёт о встроенных RI не важно какой СУБД), разница в том, что сама СУБД предоставляет возможность разработчику используя механизмы БД писать ограничения, а так же в том, что механизм запуска кода от тебя не зависит - действие с данными само инициализирует его запуск.

Владимир Максимов

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

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

Ну да, только с одним ограничением - данной "кучей" может пользоваться только один клиент (если пробовал, в 1с 7.7 удалить номенклатуру из документа, то ничего это не запрещает сделать, в интерфейсе будет отражена строчка "не найдено в справочнике").

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

Я согласен про "ежа с черепахой", только твоё замечание про "разрушить" говорит о "кривой" архитектуре либо самой СУБД либо структуры данных.

Владимир Максимов
Это к тому, что понятие "правильная" БД - сильно "растяжимое".

И с этим согласен, но это уже следствие причин вторго порядка (сделать заплатку, отсутствие времни, исправление кривизны )

Эээ - опять друг друга учите что ли ?

piva
Эээ - опять друг друга учите что ли ?

Будем!

Дело в том, что большинство людей вообще не дают себе труд задуматься, а как же работает то или иное, и почему "вот это", предпочтительнее "вот того". Как следствие, на вполне законный вопрос GotFocus "а почему, собственно?" ничего кроме истерический криков "устарело" или "отстой" и не услышишь.

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

Владимир, если на КАЖДОЕ "а почему" давать развёрнутый и аргументированный ответ на 10 страниц, то и жизни не хватит
В бытовых мелочах есть регулирующие механизмы боли, и не нужно "аргументировать" почему не стоит голым задом на горячую сковороду садится, или пальцы в розетку засовывать. В IT же такого нету, и потому собственно говоря я лично не вижу ни смысла, ни пользы "аргументировать" почему не стоит делать цикл

Или почему не нужно использовать RecNo в качестве ID, или почему не нужно в программе по кнопке удаления записи делать PACK...

Отлично - новая статья готовится

Igor Korolyov
Владимир, если на КАЖДОЕ "а почему" давать развёрнутый и аргументированный ответ на 10 страниц, то и жизни не хватит

Как правило, этого и не требуется. Кроме того, в подобных "базовых" вопросах я отвечаю скорее для себя, а не для "того парня". Пытаюсь сам разобраться правильно ли я понимаю почему следует делать так, а не иначе.

Igor Korolyov
В бытовых мелочах есть регулирующие механизмы боли, и не нужно "аргументировать" почему не стоит голым задом на горячую сковороду садится, или пальцы в розетку засовывать.

Так ведь, пока не "сунешь" или не "сядешь", так и не поймешь "почему?".

Igor Korolyov
В IT же такого нету,

Потому и нету, что далеко не каждый сталкивается с ситуацией, когда это самое "сование" приводит к проблемам. Если так получается, что всегда перед тем, как ты сунешь пальцы в розетку отключается электичество, то почему бы и не сунуть? И как объяснить, что это "не правильно"? Только включив электричество!

Igor Korolyov
и потому собственно говоря я лично не вижу ни смысла, ни пользы "аргументировать" почему не стоит делать...

Гм... Как раз потому, что вразумительного объяснений быть не может. Точнее, объяснение лежит вне программирования как такового.

PaulWist
Не согласен в другом, (речь не идёт о встроенных RI не важно какой СУБД), разница в том, что сама СУБД предоставляет возможность разработчику используя механизмы БД писать ограничения, а так же в том, что механизм запуска кода от тебя не зависит - действие с данными само инициализирует его запуск.

Так. Начнем по порядку.

"СУБД предоставляет возможность..." Замечательно. Предоставляет. А "физически" это что? Каким-таким "волшебным образом" она эту возможность предоставляет? Очевидно, что выполняется некий программный код. Другими словами, СУБД имеет уже написанную, но программу.

Может программист написать аналогичную программу? Конечно! Какие проблемы-то? Разумеется, будет написано не так, но результат будет аналогичный. Т.е. программист вполне себе способен предоставить те же самые возможности. Ну, потратив в разы больше времени, но способен.

Следующий вопрос - момент запуска этой самой программы. Опять же, каким таким "волшебным образом" база данных "узнает", что надо запустить этот программный код? По некоему событию. Чем это принципиально отличается от запуска программного кода на форме по нажатию на кнопку? Да ничем!

Чтобы было понятно, скажу то же самое другими словами:

1. СУБД имеет некий программный код (уже написанный), который она выполняет при наступлении определенного события
2. Программист пишет некий программный код, который выполняется при наступлении определенного события

И в чем разница? Только в том, что одно уже написано и протестировано миллионами пользователей, а другое еще только предстоит написать и тестировать будут хорошо если несколько человек.

PaulWist
Ну да, только с одним ограничением - данной "кучей" может пользоваться только один клиент (если пробовал, в 1с 7.7 удалить номенклатуру из документа, то ничего это не запрещает сделать, в интерфейсе будет отражена строчка "не найдено в справочнике").

С чего это вдруг? Совместный доступ как был так и остался. Вопрос ведь не в доступе, а в том, чтобы модификации данных не приводили к нарушению целостности данных. А каким образом ты этого добьешся: "руками" изменив все что нужно, написав собственную программу или используя COM-интерфейс к 1С - это уже не важно. Это твои личные проблемы

PaulWist
Я согласен про "ежа с черепахой", только твоё замечание про "разрушить" говорит о "кривой" архитектуре либо самой СУБД либо структуры данных.

Нет. Это говорит всего-лишь о том, что модификация данных произошла таким образом, что программный код, призванный контролировать целостность данных либо вообще не был запущен, либо отработал с ошибками. О "правильности" или "не правильности" архитектуры или структуры СУБД это вообще никак и ничего не говорит.

Разве архитектура или структура упомянутой тобой 1С "не правильная"? Она просто не имеет кода поддержания целостности базы в самой СУБД. Только и всего. Весь код находится в приложении.

PaulWist

Владимир Максимов
Это к тому, что понятие "правильная" БД - сильно "растяжимое".

И с этим согласен, но это уже следствие причин вторго порядка (сделать заплатку, отсутствие времни, исправление кривизны )

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

Так вот. Есть и другие стратегии написания приложений. Причем нельзя сказать, что они "хуже" или "лучше". Они просто другие.

Например, почему бы не посмотреть "с другой стороны"? Рассматривать как "главное" не данные (СУБД), а приложение?

piva
Отлично - новая статья готовится

Не... Не получится... "Водки не обещаю, но погуляем хорошо"

Обещанный ответ Владимиру Максимову на сообщение от 15.12.10 11:09:32

В общем-то согласен со всем сказанным. Хотя сделаю замечания.

1.

Цитата:

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

Какая бы навороченная не была бы СУБД, всё равно мы пишем программы. И если сравнить
объём всех наших приложений с затратами на написание попутных программ, необходимых для функционирования приложения, то они могут оказаться незначительными. В данном случае
понадобилась целостность данных - за полчаса написана. Партия скажет "Надо" и через
полчаса записи будут APPEND`иться(и даже FROM) не в конец таблицы, а на место удалённых.

2. Я пользуюсь вторым способом(ни разу не сказав что рекомендую его другим), потому что
он является для моих данных(пока всего лишь 50000 записей)(не обязательно для других),оптимальным техническим решением. Да, экономия небольшая. Кстати

Цитата:

это 4 байта Integer

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

3. Если глянете на вопрос темы - меня просто интересовало, а возможен ли второй способ
в C# c его DataTable. Думаю что нет. Зато получил массу полезной информации.
Новые технологии будут использованы мною в полном объёме(по мере необходимости).
Всем спасибо !



Исправлено 1 раз(а). Последнее : GotFocus, 15.12.10 23:34

Владимир Максимов

PaulWist
Не согласен в другом, (речь не идёт о встроенных RI не важно какой СУБД), разница в том, что сама СУБД предоставляет возможность разработчику используя механизмы БД писать ограничения, а так же в том, что механизм запуска кода от тебя не зависит - действие с данными само инициализирует его запуск.

Так. Начнем по порядку.
...

Чтобы было понятно, скажу то же самое другими словами:

1. СУБД имеет некий программный код (уже написанный), который она выполняет при наступлении определенного события
2. Программист пишет некий программный код, который выполняется при наступлении определенного события

И в чем разница? Только в том, что одно уже написано и протестировано миллионами пользователей, а другое еще только предстоит написать и тестировать будут хорошо если несколько человек.

Нет, разница в том, что в СУБД программный код интегрирован с данными (это часть данных), а то что пишет программист (если конечно это не СУБД) программный код является клиентом к данным.

Владимир Максимов

PaulWist
Ну да, только с одним ограничением - данной "кучей" может пользоваться только один клиент (если пробовал, в 1с 7.7 удалить номенклатуру из документа, то ничего это не запрещает сделать, в интерфейсе будет отражена строчка "не найдено в справочнике").

С чего это вдруг? Совместный доступ как был так и остался. Вопрос ведь не в доступе, а в том, чтобы модификации данных не приводили к нарушению целостности данных. А каким образом ты этого добьешся: "руками" изменив все что нужно, написав собственную программу или используя COM-интерфейс к 1С - это уже не важно. Это твои личные проблемы
...

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

Владимир Максимов

PaulWist
Я согласен про "ежа с черепахой", только твоё замечание про "разрушить" говорит о "кривой" архитектуре либо самой СУБД либо структуры данных.

Нет. Это говорит всего-лишь о том, что модификация данных произошла таким образом, что программный код, призванный контролировать целостность данных либо вообще не был запущен, либо отработал с ошибками. О "правильности" или "не правильности" архитектуры или структуры СУБД это вообще никак и ничего не говорит.
...

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

Владимир Максимов
Разве архитектура или структура упомянутой тобой 1С "не правильная"? Она просто не имеет кода поддержания целостности базы в самой СУБД. Только и всего. Весь код находится в приложении.

Ну вот приехали...

О какой правильности может быть речь если хранилище НИКАК не защищено - как раз это нонсенс.

Ну если ты считаешь, что это правильно и так нужно/можно делать, то чЁ мы "пинаем" автора топика, он то как раз так и делает... и "видал" он всякие PK/FK с триггерами и иже с ними, у него и так всё работает

(GotFocus мои слова лично к Вам не относятся, просто мы в Вашем топике )

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

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

Да, и считаю, что так должно быть, не должны данные зависеть от клиента иначе это абсурд.

Владимир Максимов
Так вот. Есть и другие стратегии написания приложений. Причем нельзя сказать, что они "хуже" или "лучше". Они просто другие.
Например, почему бы не посмотреть "с другой стороны"? Рассматривать как "главное" не данные (СУБД), а приложение?

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

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





Исправлено 2 раз(а). Последнее : PaulWist, 15.12.10 23:19

GotFocus
Обещанный ответ Владимиру Максимову на сообщение от 15.12.10 11:09:32
В общем-то согласен со всем сказанным. Хотя сделаю замечания.

1.

Цитата:

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

Какая бы навороченная не была бы СУБД, всё равно мы пишем программы. И если сравнить
объём всех наших приложений с затратами на написание попутных программ, необходимых для функционирования приложения, то они могут оказаться незначительными. В данном случае
понадобилась целостность данных - за полчаса написана. Партия скажет "Надо" и через
полчаса записи будут APPEND`иться(и даже FROM) не в конец таблицы, а на место удалённых.

А не лучше это время потратить на что-то более полезное?

Цитата:

2. Я пользуюсь вторым способом(ни разу не сказав что рекомендую его другим), потому что
он является для моих данных(пока всего лишь 50000 записей)(не обязательно для других),оптимальным техническим решением. Да, экономия небольшая. Кстати

Цитата:

это 4 байта Integer

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

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

Цитата:

3. Если глянете на вопрос темы - меня просто интересовало, а возможен ли второй способ
в C# c его DataTable.

Коипруйте содержимое в массив и получите искомое. Вот только стОит ли.

Пользуясь случаем, задам вопрос. Допустим я начал использовать Database(а не свободные таблицы). И при неработающей моей программе кто-то(или вирус) слегка изменил файлы,
входяшие в Database.
Захожу в программу и что будет ? Если Database следит за такими вмешательствами,
то буду её использовать с завтрашнего дня.



Исправлено 1 раз(а). Последнее : GotFocus, 16.12.10 10:47

GotFocus
Пользуясь случаем, задам вопрос. Допустим я начал использовать Database(а не свободные таблицы). И при неработающей моей программе кто-то(или вирус) слегка изменил файлы,
входяшие в Database.
Захожу в программу и что будет ? Если Database следит за такими вмешательствами,
то буду её использовать с завтрашнего дня.

Понимаете, здесь важно через что "кто-то или вирус" захотят поправить файлы, если через штатный доспуп к данным ODBCC/OleDB/COM/итд, то СУБД при правильном написании не даст испортить данные (возьмите мой пример и попробуйте из фокса или через OleDB Provider удалить шапку или ввести в детали значения не существующие в шапке - не получится).

Конечно, если взять любой редактор и поправить "руками" файлы БД, либо физически диск посыпался,... тут как говорится ... "против лома нет приёма" , те можно "убить" ЛЮБУЮ БД, любого производителя, но мы об этом не ведём речь.

Вот тут я скажу разработчикам этой Database - Туфта эта ваша Database. Писали вы,
писали, так ничего и не написали.

GotFocus
Вот тут я скажу разработчикам этой Database - Туфта эта ваша Database. Писали вы,
писали, так ничего и не написали.

Очень смешно. Типа разработчики всех субд лохи по сравнению с GotFocus. Который, правда, тоже никак не может защититься от прямого изменения байтиков в файле. Очень остроумно.

GotFocus
Вот тут я скажу разработчикам этой Database - Туфта эта ваша Database. Писали вы,
писали, так ничего и не написали.

Ну да, а так же туфта у производителей: то у них подшибноки выходят из строя, то магнетик сыпится, то головка заедает, то "мать умрёт", то check sum памяти не проходит, то сетевуха сгорит, то разьём окислится, то...

Цитата:

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

Возрожу ! Я защитился ! Своими программками, написание которых Вы не приветствуете

GotFocus

Цитата:

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

Возрожу ! Я защитился ! Своими программками, написание которых Вы не приветствуете

Код и данные в студию. Для проверки как Ваш код восстановит данные, порушенные прямым изменением байтов в файле данных.