К списку форумов К списку вопросов
Какие программы продаются?
alex111
15.04.2004 - 16:48
Какие программы стоит делать в СУБД (Foxpro)чтобы можно было впоследствии их продавать?
Big Duck
1 - 15.04.2004 - 17:11
Продать можно то, что кому-то нужно!
А это что-то написанное на заказ и потрясающе узкоспециализированное!
Можно конечно изобрести еще один велосипед, но тогда надо долго доказывать, что он лучше тех, которые существуют.......
------------------
А почему именно Fox?
Чувак
2 - 15.04.2004 - 17:53
Пиши лучше под MySql, весит немного и в работе намного лучше.
Big Duck
3 - 15.04.2004 - 18:05
MySQL ?!
Не делайте мне смешно! - это ж просто набор табличек! без хранимых процедур, без триггеров!.......
В одной из последних версий хоть ключи появились....... - не! на MySQL ничего серьезного делать в принципе нельзя!
AI
4 - 15.04.2004 - 19:17
for 3
а что ты серьёзного делал? :-)
LF
5 - 15.04.2004 - 20:55
AI: а какую ТЫ пользу видишь от триггеров, хранимых процедут?
Big Duck
6 - 15.04.2004 - 22:48
for 4
Тут хвастаться не буду (смысла нет), но скажу что делал!
Серьезную базу без триггеров писать весьма проблематично - слишком много кода таскать приходится, а без ключей как целосность базы контролировать? тоже все в коде оболочки?!.... да и извне софтины с базой не поработаешь - элементарно, надо что-то залить, но при это должны добавиться/измениться другие записи или того интереснее удалить! - тогда целосность нарушается элементарно. Тот кто извне пытается это сделать может не знать всех ньюансов, поэтому это обязательно должно быть в триггерах!
Тупой ламер
7 - 16.04.2004 - 11:52
если брать более обще, то наличие в базе триггеров - это признак наспех сделанной или постоянно "латаемой" базы.
есть много причин, которые выносят это на уровень одной из пардигм проекта.
целостность и корректность данных в нормальных базах нужно реализовать исключительно на уровне бизнес логики базы, реализуемой в хранимых процедурах.
замечу, что клиентское приложение в нормальных приложениях никогда не должно общаться ни с чем иным, как с уровнем бизнес-логики базы - таблицы напрямую для приложения не должны существовать вообще.
Тупой ламер
8 - 16.04.2004 - 11:57
прошу простить за многочисленную тавтологию в тексте - сумбур в мыслях по причине загруженности
Big Duck
9 - 16.04.2004 - 12:10
А что такое триггер в таком случае?!
Триггер - это та же самая ХП, только она отрабатывается по требуемому событию!
Ты правильно сказал, что вся логика должа быть в процедурах и никак не касться самой оболочки! Но вот утверждение того, что "наличие в базе триггеров - это признак наспех сделанной или постоянно 'латаемой' базы" диаметрально-неверное!!
Тупой ламер
10 - 16.04.2004 - 13:10
ох, как я хорошо покуууушал... ;-)
мда
жизнь - это обеды и то, чем мы заполняем пустоту между ними
насчёт триггеров
выделение обработки части логики общения с объектом БД в виде триггера (если более конкретно - проверка уникальности кортежа, корректрость данных, дублирование, нотификация иных объектов and etc...) - нехорошо по многим причинам, я приведу всего лишь несколько.
- Непрозрачность базы. Изменилась, к примеру, или добавилась некоторая сущность, а чтобы учесть её, вам нужно будет вспоминать, в каких триггерах её надо подключить, а вкаких что поотключать. В случае же реализации в интерфейсных процедурах/пакетах вы всегда знаете, где нужно менять. К тому же в случае совместной разработки, где слабая взаимосвязь между разработчиками БД - эти клятые триггеры порой превращаются в ящик Пандоры, уж поверьте. Таблин сотен эдак несколько, ближе к тысячи, а мой простейший insert вылетает, причём чёрт его знает почему. Зачем тратить время на разборку с чужой логикой? Али шлюзовые интерфейсы не про нас придуманы?
- Ограниченность. В триггерах есть ограничения. Нельзя в update делать подзапрос по самой себе (Oracle) или ещё что... Самое пакостное, что эти ограничения зависят от платформы БД (если вы переносили крупную базу в платформы на платформу - вы опять-таки - меня поймёте). В случае же хранимых процедур - всё гооораздо проще с переносом.
- Производительность и механизмы выполения запросов с учётом триггеров. Оччень критичный и важный пункт во многих случаях. Триггер всегда медленнее куска кода перед операцией, требующей триггера. Порой - слишком медленнее. К тому же у разрабьотчика должна болеть голова, как изменится профиль выполнения кода в случае добавления-удаления триггера. А таблиц опять же сотни, а триггеров чёрт его знает сколько, а мест в хранимках, где это может пересекаться не сотни - десятки тысяч! Это я ещё скромно, кстати. И получается, что в некоторых местах надо триггеры отключить для скорости, а в некоторых они просто не нужны, а если блин идёт репликация по серверам, а если грязное чтение..?
три пункта, я думаю, хватит, хотя я могу ещё - хотя не, не могу, ибо включаюсь в процесс зарабатывания денех для себя, любимого :-)
В общем, получается кю. В смысле не будем множить сущностей без надобности, а то придёт дядя Оккам со своим лезвием и как серпом по ... хм.
Если же сказать одной фразой, то триггер - это перенос части бизнес логики непосредственно на объекты БД - что само по себе кю.
AI
11 - 16.04.2004 - 13:24
for LF (5)
я хранимые процедуры юзаю. но не в мусккуле :-) . в 5 будет наконец то тоже. Хотя грозились что в 4-ом всё будет - фиг там кроме вложенных запросов ничего путёвого нет ну и кучу агрегарных функций новых да маразма с разницей API функций для С++ . Хранимые процедуры я использую для реализации нечто 'базовых функций' для бизнес правил. в MSSQL правда :-)
Big Duck
12 - 16.04.2004 - 13:36
В принципе не согласен!!
Если какую-то информацию в базе необходимо обработать из разным мест в интерфейсе, то что, будем куски кода таскать? а смысл? Именно тут и заключается неудобство того, как ты говорил, что в базе
"....добавилась некоторая сущность, а чтобы учесть её, вам нужно будет вспоминать, в каких триггерах её надо подключить, а вкаких что поотключать. В случае же реализации в интерфейсных процедурах/пакетах вы всегда знаете, где нужно менять..."
как раз наоборот! триггеров будет гораздо меньше! чем процедур в интерфейсе, которые по сути могут проделывать аналогичные действия!
"...К тому же в случае совместной разработки, где слабая взаимосвязь между разработчиками БД..."
где это ты видел слабую связь между разработчиками в совмесном проекте?! Если она работают вместе - значит связь по дефолту должна быть наилучшей! а если каждый сам в своих процедурах пишет одно и то же!! что и другие.... (причем, кто-то менее осведомленный в бизнес-логике может допустить ошибки и отлавливать их будет одно удовольствие - тут работает, а тут то же самое нет!!) - это уже не программирование! студенты первокурсники знают такое оптимизация! А если же есть триггер, то разработчику оболочки и задумываться не надо о тех тонкостях, которые заложены ниже! Триггер сам проверит и доделает все что надо, в случае чего поднимер эксэпшн! а разработчику оболочки остается его только обработать красиво...
Поэтому в случае командной разработки без триггеров вообще не обойтись! - иначе сама оболочка будет перегружена дублирующимеся, совершенно не нужными кусками! причем вероятность ошибки при этом увеличивается в разы! и именно поэтому нужно использовать триггеры/ключи и прочие инструменты контроля целостности
Тупой ламер
13 - 16.04.2004 - 14:08
классно я-таки покушал всё же, до сих пор не работается :-)
Вы, как я вижу, не вполне поняли, что я написал. Или я не так это донёс.
Я упоминал понятие интерфейсных процедур/пакетов, которые, по сути, являются частичным переносом объектной модели на реляционную БД. А это значит, что во всей базе не будет двух дублирующих реализацию кусков кода. То есть вообще не будет. Точка входа на доступ к объекту только одна - её реализация и меняется. Все иные процедуры общаются с выделенным объектом только через этот интерфейс.
студенты-первокурсники возможно и знают, что такое оптимизация, но, и я не видел исключений, писать оптимально не умеют - это как раз то, что приходит только с опытом... я сам таким был.
Возможно, вы и и работаете с идеальной командой разработчиков, но, увы мне - я работаю с реальными людьми, у нас огромная база, которой не один и не три года, терабайты информации (если считать по всей базе, с включёнными в репликацию и прямыми линками серверами), и более десятка человек, с разной квалификацией и стилем работы. И все чертовски заняты. И чтобы получить ответ на мой вопрос по части базы, мне порой приходится ждать, чтобы мой сосед (сидит за стенкой) освободился, до суток... и что же мне - сутки маньку валять в серврерной на горячем распред-щите?
впрочем, я всегда считаю, что любое решение человек принимает для себя сам на основе своих собственных ошибок и опыта.
мой опыт, значит, с вашими областями работы не пересекается
ps. вы не опровергли ни одного пункта, которые я для примера поставил в минусы использованию триггеров...
Big Duck
14 - 16.04.2004 - 14:33
Итак, начнем:
-Непрозрачность базы. Здесю ключевое слово "БАЗА". Если требуется узнать что-то именно из базы! просмотреть тех-процесс или что-то еще - просмтотром таблиц и процедур не ограничишься - надо лезть еще в код оболочки, куда вынесен функционал триггеров. Так же, если меня надо сделать некий импорт в базу - это что, обязательно в основной софтине надо писать какой-нить плагин импорта, чтобы он опять же юзал интрефейс-процедуры вместо триггеров? Это уже лишняя работа! Гораздо проще написать какие надо инсерты, а триггера сами все доделают! и не надо лезть в оболочу!
В итоге получается, что с такой базой можно работать ТОЛЬКО из софтины-оболочки - это не минус?
-Ограниченность. update с подзапросом по самой себе (в IB/FB во всяком случае) работает совершенно нормально - проверял. Платформа Linux (дистрибутив точно не скажу ибо не знаю....) По-поводу миграции ничего сказать не могу - не приходилось этим заниматься. Но точно могу сказать, что вышеперечисленных проблем я не встречал.
-Производительность и механизмы выполения запросов с учётом триггеров. Значит триггер работает медленнее? это почему же? если у нас клиент-сервер, то не важно откуда поступил код - из интерфейс-процедуры, хранимой процедуры или триггера - все равно обрабаьывать это дело будет сервер! скорость выполнения может колебаться от загрузки самого сервера, но никак не от того, что какие-то запросы написали в интерфейсе и передали на тот же сервер! То, что таблиц сотни не страшно - вовсе не обязательно разводить что-то в интерфесе "а то триггер делает много лишнего".... просто в самом триггере надо проверять ЧТО изменилось и в зависимости от этого проделывать те или иные действия - нам ничего не мешает заложить в сам триггер определенную логику. Поэтому триггеры отключать не надо - надо его просто нормально спроектировать. то же самое касается "грязного чтения" - это вопрос построения индексов и грамотного формирования запросов. К тому же большинство серверов позволяют писать планы выполнения (на тот случай если свой оптимизатор ведет себя непристойно)
-----------
а насчет команды - да, я действиетельно работаю в сильной команде, но мне ни разу! не приходилось ждать сутками нужного мне ответа (хотя проект у нас тоже весьма не малелький!) - именно потому, что вся логика и техпроцессы находятся именно в базе! а оболочка - на то она и оболочка! просто интерфейс!
Тупой ламер
15 - 16.04.2004 - 15:19
мда..., назвался груздем, не говори, что своя рубашка ближе к телу :-(
чем дальше, тем больше я понимаю, что мы говорим на разных языках
потому этот ответ последний
-"Если требуется узнать что-то именно из базы! просмотреть тех-процесс или что-то еще - просмтотром таблиц и процедур не ограничишься - надо лезть еще в код оболочки, куда вынесен функционал триггеров" - техпроцесс это штука тонкая и сложная. И меняется часто. У нас в команде каждый отвечает за свои техпроцессы и я ещё ни разу не пытался понять чужой - мне это будет только мешать, а не помогать, не говоря уж о времени. Для того же, чтобы общаться с этим техпроцессом (для меня чужим) - этот человек и пишет для меня и всех универсальные интерфейсы доступа (причём они могуть быть пустышками, в чём прелесть скорости их реализации). А в какие таблицы он потом начнёт пихать то, что я ему подаю на вход - увольте! А если он решит переработать структуру своих таблиц? Зачем мне тогда об этом вообще думать?!
"если меня надо сделать некий импорт в базу ... чтобы он опять же юзал интрефейс-процедуры вместо триггеров" вы это о чём, любезный? как можно вызвать триггер? вы, я вижу, будете явно делать insert,update, delete таблицы, что, я считаю, вообще пакость, ибо кто вам права даст на таблицу из чужой зоны ответственности?! Права пользователя (а я, даже как разработчик, для другого разработчика тоже пользователь, просто с расширенными правами) должны ограничиваться на уровне бызнес-логики, на таблицы вообще никаких прав! Неужели у вас в проекте есть возвожность, например, мне напрямую грохнуть таблицу, за которую отвечает другой разработчик? Слабо верю для крупного проекта.
А импорт делается отдельным интерфейсом (у нас, например). Для Oracle есть отличный механизм ORA-Loader для быстрого обмена большими объёмами данных - никакие групповые механизмы переливки не сравнятся по скорости. Возможно, и для других БД есть подобное.
-Ограниченность триггеров. Если вы работали с серьёзными БД, типа Oracle, MS SQL или хотя бы сибейза, то тут не было бы никаких вопросов. IB я, правда, не использовал ни разу, может, у него всё и можно.
- Скорость. Если вы знаете, какова цепочка выполнения запроса от начала до выдачи данных (на уровне реализации сервера), то какие могут быть вопросы? Триггеры не могут ни в каком варианте работать быстрее прямого кода, уж поверьте...
всё, хватит...
ой, да... насчёт "Поэтому триггеры отключать не надо" - вы явно не работали с таким зверем, как онлайн-репликация серверов и распределённые БД :-)
Big Duck
16 - 16.04.2004 - 15:42
Согласен, что в ту логику, которую пишет другой разработчик лезть без необходимости не стоит, но к триггерам это мало отношения имеет. Все что пишет отдельный разработчик так же можно внести в триггер и разводить по каким-то признакам (сделать какую-то логику в триггере). К тому же, насколько я понимаю, у каждого более или менее верьезного проекта есть руководитель, который в курсе всех манипуляций остальных разработчиков и которому не стоит накаких проблем разобраться во внешне большом триггере... Это же касается и переработки таблиц - руководитель просто все это координирует.
Да! Буду делать какой-то инсерт, причем я сам, как разработчик - никому постороннему я не дам на это прав. - Элементарная ситуация: надо что-то залить в базу - можно посадить юзера набивать (у него на это уйдет два дня) или мне написать небольшой инсерт не задумываясь о том, что находится ниже!! У нас все разработчики имеют админские права и теоретически могут погрохать таблицы, но... НО!! у нас не такого понятия - это твои таблицы, а это мои! - у нас есть НАШ проект, просто кто-то реализовывает одну часть, кто-то другую и при это могут обращаться ко всем таблицам, процедурам и т.д.
Поэтому используя любой инструмент для работы с БД (тот же IBExpert) я могу делать с базой все что угодно! и не переживать, что я что-то сломаю - те же триггеры не дадут мне удалить важные записи!
Все равно не согласен с тем, что триггер работает медленнее!! - запрос обрабатывает сервер!
----------
И рекпликация удаленных баз с основной у нас идет на "УРА" без отключения триггеров - просто они разведены как надо.
----------
В итоге, как резюме могу предположить, что у вас сам техпроцесс написания софта поставлен несколько неправильно (прошу прощения, но мне так кажется) - получается нет человека, который рулит ситуацией и в курсе всех событий. А это важно!
И еще чисто философский вопрос напоследок: а зачем тогда придумли триггеры? Это ламерство? Мож тогда и ключи не нужны и индексы? :) почему бы тогда данные в тексвтовом файле не хранить?!
Я конечно утрирую, но тем не менее....
alex111
17 - 17.04.2004 - 13:35
Увы прошли золотые 90-е годы, когда за вечер можно было на Foxpro 2/6 сделать какую-нибудь "лабуду" для бухгалтерии типа программки начисления налога на благоустройства города и на следующий день положит за нее в карман месячный оклад рабочего.
Мне тут на соседней опции предложили как-бы объединиться и сделать свой комплекс. Ха! Поконкурировать с таким монстром как 1С. Смешно. Так что же переквалифицироваться в управдомы как говорил О. Бендер?
alex111
18 - 17.04.2004 - 13:38
На FoxPro делаю, потому что больше ни на чем не делал. (Ну в колледже на Basic когда-то). Написал платежные поручения, для милиции, для библиотеки но это все разовые и недорогие.
alex111
19 - 17.04.2004 - 16:46
кстати у меня вопрос к Тупому ламеру и большой утке: Вы к примеру над какими программами работаете сейчас?

К списку вопросов на форуме Программирование

>>