![]() |
![]() |
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 | кстати у меня вопрос к Тупому ламеру и большой утке: Вы к примеру над какими программами работаете сейчас? |