Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 23   вперед  Ctrl
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
а мы все здесь люди простые - между строк читать не умеем. раз человек пишет, что (про опытных разработчиков - см. выше), значит, понимается, что он именно эту мысль и хочет всем донести, а не какой-то там скрытый между первым и третьим словом смысл.

К сожалению вы как раз и пытаетесь читать между строк, причем читать то, чего там нет. Приплели како-то визард, которого в ФМ нет, небыло и, надеюсь, никогда не будет. С чего-то взяли что ФМ может по эскизу экранной формы сгенерировать структуру БД. В общем полный бред. Ничего подобного я не писал, ни между строк, ни в строках. Мысль, которую я "хотел всем донести" звучит так: по эскизу экранной формы ФМ можно довольно точно представить себе скрытую за ней структуру БД. Если один опытный разработчик ФМ нарисует и опишет эскизы всех основных экранных форм БД, то другой опытный разработчик ФМ сможет в точности воспроизвести структуру БД, которую задумал первый, но воспроизводить он будет её ручками - каждое поле, каждую связочку по отдельности. По этой технологии я работаю удаленно на американцев уже несколько лет. Эту технологию предложили мне они - я её не придумывал. Так что, когда вы называете эту технологию ересью и пороком, вы пытаетесь спорить с очень опытными менеджерами проектов из США, что, ИМХО, просо глупо, тем более что один из моих менеджеров ораклоид с 15-ти летним стажем.

BTW, по поводу транзакций: нигде, ни в документации по ФМ, ни в литературе по ФМ, ни на итернет-сайтах посвященных ФМ, ни в мейл-листах термин "транзакция" просто не используется. Так что, можете засунуть этот термин себе куда-нибудь поглубже.
10 сен 04, 16:21    [951868]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Термин то засунуть можно, только как быть с целостностью ?
Визуальный интерфейс и бизнес логика - РАЗНЫЕ СЛОИ, очень редко и в очень простых приложениях они отображаются друг в друга одын в одын.
Начинать разработку с визуального интерфейса можно (дело вкуса), но нужно осознавать, что разработка бизнес-логики это совершенно отдельный и не зависимы процесс.

P.S. "Огры любят ЛУК"
10 сен 04, 16:27    [951912]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
mv
Member

Откуда:
Сообщений: 8876
В общем, юзайте ECO (или Bold for Delphi) (ай-яй, только не по голове!).
10 сен 04, 16:28    [951927]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
2АЗ:
а кто писал, что разрабатывая клиентскую часть, мы автоматически получаем серверную?

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

насчёт ереси, вы всё перепутали - я нигде ранее так не отзывался фм. даже наоборот: писал, что это очень даже продвинутый продукт.
вот даже ваше последнее утверждение:
АЗ
нигде, ни в документации по ФМ, ни в литературе по ФМ, ни на итернет-сайтах посвященных ФМ, ни в мейл-листах термин "транзакция" просто не используется

лишний раз подтверждает, что компания ФМинк шагнула так далеко по пути прогресса, развития и внедрения в жизнь новых технологий, что термин "транзакция" - это уже изживший себя анахронизм. Поэтому можно смело утверждать, что ФМ-сервер становится (или уже стал) мировым лидером в области обработки данных
10 сен 04, 16:47    [952031]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
а кто писал, что разрабатывая клиентскую часть, мы автоматически получаем серверную?

Я писал. Могу написать что разрабатывая серверную часть, мы автоматически получаем клиентскую. Сути это не меняет. БД ФМ не делят на клиентскую и серверную части. Исключение составляют так называемые Front-end системы, но это - трудоемкий метод разработки. Без особой необходимости его не используют.


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

В небольших консалтинговых компаниях функции менеджера проекта выполняет ведущий программист.


насчёт ереси, вы всё перепутали - я нигде ранее так не отзывался фм
\
Насчет ереси я писал не Вам, а вам.
10 сен 04, 17:34    [952278]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Gluk (Kazan)
как быть с целостностью ?

Целостность мы обсуждали на двенадцатой странице. Думаю хватит уже переливать из пустого в порожнее.


Визуальный интерфейс и бизнес логика - РАЗНЫЕ СЛОИ

Давайте в очередной раз определимся с терминологией. Возьмем типичную для ФМ задачу: CRM + договора, счета, накладные и платежи. Объясните мне п-ста где здесь разные слои? Что в данной задаче является "бизнес логикой"?
10 сен 04, 17:47    [952305]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Gluk (Kazan)
Визуальный интерфейс и бизнес логика - РАЗНЫЕ СЛОИ, очень редко и в очень простых приложениях они отображаются друг в друга одын в одын.

Вы кажется не поняли главного: В ФМ нельзя создавать таблицы или поля в процессе работы системы, в ФМ даже переменных нет - их функцию выполняют глобальные поля. Поэтому структура БД ФМ и её интерфейс тесно взаимосвязаны. Бессмысленно проектировать структуру БД ФМ отдельно от интерфейса, - потом, при разработке интерфейса её наверняка придется корректировать.
10 сен 04, 18:47    [952469]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Согласен
Guest
Александр Зуев
Gluk (Kazan)
Визуальный интерфейс и бизнес логика - РАЗНЫЕ СЛОИ, очень редко и в очень простых приложениях они отображаются друг в друга одын в одын.

Вы кажется не поняли главного: В ФМ нельзя создавать таблицы или поля в процессе работы системы, в ФМ даже переменных нет - их функцию выполняют глобальные поля. Поэтому структура БД ФМ и её интерфейс тесно взаимосвязаны. Бессмысленно проектировать структуру БД ФМ отдельно от интерфейса, - потом, при разработке интерфейса её наверняка придется корректировать.

А если возникает потребность обратиться к БД, которая получилась в результате проектирования из другого приложения с другим интерфейсом ? Придется ли в этом случае изменять БД и, соответственно, изменять интерфейс первого приложения ?
10 сен 04, 19:01    [952490]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Согласен
А если возникает потребность обратиться к БД, которая получилась в результате проектирования из другого приложения с другим интерфейсом ? Придется ли в этом случае изменять БД и, соответственно, изменять интерфейс первого приложения ?

Если второе приложение устраивает то, в каком виде хранятся нужные данные в первом приложении (их структура), - ненужно. Более того, наладив связь между двумя приложениями Вы можете продолжать модификацию обоих приложений, к примеру, Вы можете изменить имена полей, удалить поля не использующиеся вторым приложением или добавить новые. То же самое со скриптами. Имена полей ФМ использует только в момент составления некоторой формулы в диалоговом окне. Как только программист нажимает ОК ФМ как бы компилирует введенную формулу и заменяет внутри себя имена объектов их идентификаторами, при этом форматирование формулы (пробелы, переводы строки и пр.) сохраняется.
10 сен 04, 19:43    [952550]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Пример бизнес логики? Да легко, только для еще более примитивной задачи(KLADR):

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

Если все счета, накладные и т.д. заполняются в ручную - то наверное никакой бизнес логики не надо. Если изменение какого-то поля влечет какие-то другие изменения или есть процедуры требующие нетривиальных вычислений - то извините. Я так понимаю ввод платежей изменяет остатки на счетах? Или их надо в другой форме руками исправлять? Или на изменение поля пишется событие, которое меняет другие таблицы - а если оно в 10 местах меняется? А если есть архивирование данных? Т.е. есть задачи которые прямо с интерфейсом не связаны и которыми должен заниматься сервер.
Вобщем везде есть разделение на бизнес логику и интерфейс, и у Вас тоже.

Что лично мне не нравиться в ФМ из того что я тут прочитал:

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

2. Нестандартный способ манипуляции данными. Я так понимаю используется исключительно навигация и нет массовых операций с данными(чтобы изменить несколько записей по определённым условиям надо писать циклы). Даже если они и есть - всё-таки SQL, несмотря на наличие разных диалектов, поддерживается во всех СУБД.
10 сен 04, 19:49    [952559]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Согласен
А если возникает потребность обратиться к БД, которая получилась в результате проектирования из другого приложения с другим интерфейсом ? Придется ли в этом случае изменять БД и, соответственно, изменять интерфейс первого приложения ?

Если второе приложение не устраивает в каком виде хранятся нужные ему данные в первом приложении, то в одном из приложений можно создать какое-то кол-во дополнительных калькулируемых полей, которые преобразуют данные в нужный вид. На интерфейс первого приложения это не повлияет.
10 сен 04, 19:51    [952560]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
after_fm
Да там так же можно проектровать структуру и связи между таблицами, как в любом другом редакторе СУБД. Создаёшь поле, указываешь тип, создаёшь индекс! Вручную!

АЗ
Вы кажется не поняли главного: В ФМ нельзя создавать таблицы или поля в процессе работы системы

чета я ваще ниче не понимаю... видать левумод меня по голове ударил...

в ФМ даже переменных нет - их функцию выполняют глобальные поля.

точно левумод

угугуй!!!
уже 14-ая страница!!!
10 сен 04, 20:00    [952565]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Лох Позорный
after_fm
Да там так же можно проектровать структуру и связи между таблицами, как в любом другом редакторе СУБД. Создаёшь поле, указываешь тип, создаёшь индекс! Вручную!

АЗ
Вы кажется не поняли главного: В ФМ нельзя создавать таблицы или поля в процессе работы системы

чета я ваще ниче не понимаю...

Эти два замечания не противоречат друг другу. after_fm писал о проектировании (создание таблиц, полей и пр.), а я о работе системы (ввод/вывод данных). Таблицы и поля в ФМ создаются вручную. Команды типа create table #t(i int) в ФМ нет.
10 сен 04, 20:20    [952577]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
Пример бизнес логики? Да легко, только для еще более примитивной задачи(KLADR):

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

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



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

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



Вобщем везде есть разделение на бизнес логику и интерфейс, и у Вас тоже.

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

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



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

В ФМ интерфейс получается хороший только лишь потому, что он (ФМ) имеет хороший инструмент разработки интерфейса, который в отличии от большинства других систем как раз НЕ ограничивает разработчика. А привязка к серверной части на интерфейс никак не влияет. Просто в ранних версиях ФМ всё (экранные формы, скрипты, структура БД и сами данные) хранилось в одном файле - одна таблица на файл. В ФМ7 появилась возможность создавать неограниченное кол-во таблиц в одном файле и отделить данные от экранных форм, скриптов и реляций, но данные и описание их структуры попрежнему едины.

Насчет "монстрообразных псевдотаблиц" я не очень понял о чем Вы. Дело в том что "псевдотаблиц" в ФМ вообще нет, а "монстрообразные" системы в ФМ, ИМХО, делать неэффективно. Я никогда не делал систем, в которых было бы больше 30 таблиц. Больше 800 полей на таблицу тоже небыло, обычно не более 50-100 полей. Я правда слышал о таблицах на 1500 полей и более, слышал я и о системах на 100 и более таблиц, но типичным проектам ФМ такие масштабы несвойственны. А вто система со 100 и более экранными фомами - это для ФМ самое то.



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

Ну незнаю. Когда речь идет о "массовых операциях" цикл не кажется мне нестандартной операцией. В принципе в ФМ есть команда Replace[] - замена данных по одному полю по всей таблице, но это, по сути, тот же цикл. Вообще-то, в системах ориентированных на интерфейс потребность в массовых операциях встречается довольно редко.
10 сен 04, 21:36    [952634]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Я долго это читаю, давно такого небыло,
но вот это меня добило в конец...

Я никогда не делал систем, в которых было бы больше 30 таблиц.

О чем, тогда может быть спор???

слышал я и о системах на 100 и более таблиц, но типичным проектам ФМ такие масштабы несвойственны.

Это называется маштабами???
11 сен 04, 12:38    [952865]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
DimaR
О чем, тогда может быть спор???

А что Вас смущает?

FileMaker Server—Server software ideal for hosting databases across large workgroups (up to 250 simultaneous guests and 125 hosted files) - это про сервер для ФМ 6, там 1 файл = 1 таблица. В ФМ 6, если кол-во таблиц превышало возможности сервера ставили два и более серверов, но это - мало кому нужно было. В ФМ 6 нам часто приходилось собирать логически разные данные, которые не требуют доступа в режиме List View (типа справочников и пр.), в одну таблицу.

Недавно вышел ФМ 7. У его сервера попрежнему ограничение на кол-во файлов (125), но каждый файл может содержать неограниченное кол-во таблиц. Так что, будем осваивать новые горизонты.

А насчет того, о чем спор - прочитайте внимательно название этого топика.
11 сен 04, 14:10    [952893]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
АЗ
Больше 800 полей на таблицу тоже небыло, обычно не более 50-100 полей. Я правда слышал о таблицах на 1500 полей

это уже даже не смешно. 50-100 полей держите меня семеро. Александр, Вы вообще имеете хоть какое-то представление о теории реляционных баз данных? или только понаслышке?

SergSuper
всё-таки SQL, несмотря на наличие разных диалектов, поддерживается во всех СУБД.

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

DimaR
О чем, тогда может быть спор???

ну если, скажем, в каждую таблицу запихнуть по полторы штуки полей, то тут ого-го чего получается
11 сен 04, 14:54    [952904]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
это уже даже не смешно. 50-100 полей

А что смешного?

Есть такая контора Schawk, Inc. Крупная, трансконтинентальная препресс компания с офисами в США и Азии. Среди её клиентов Nike, Calvin Klein, Nestle, Procter & Gamble и всякая прочая круть. У них свой штат ФМ разработчиков, которые занимаются разработкой и поддержкой системы SchawkLink. Система дико навороченная. Я бы многое там переделал и упростил, но не в этом дело. Незнаю по каким причинам, толи у них времени не хватало, толи опыта, но в конце 2001 года они заказали нам разработать для своей системы одну маленькую фьючу - иерархический редактор с неограниченным уровнем вложенности. Последнее (неограниченную вложенность) оказалось довольно сложно реализовать в ФМ. Начального эстимейшена (40 часов работы) нехватило. За 62 часа я разработал им то, что нужно. В результате получилась одна таблица на 114 полей и кучей внутренних реляций. Позже, в конце 2002 года они удалили кое-что в своей системе и самостоятельно перенесли некоторые части моего иерархического редактора, а чтобы убедиться что не напортачили прислали переделанную систему мне на проверку с таким комментарием: "I know our client felt shy about removing it because he doesn't really understand the hierarchy editor and was afraid of breaking it."

Так что, если Вы имеете представление о теории реляционных баз данных, то должны вероятно понимать, что сложность РБД зависит от её структуры, а не от кол-ва полей.
11 сен 04, 16:35    [952968]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
автор

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

АЗ говорил. Да и к документации отсылал... И чо судить-то по названию? если исходить из названий, то "Огненная птица" - вообще персонаж детских сказок :-)

автор

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

а это смотря что делаешь. у меня к примеру есть несколько сааавсем ненормализованных таблиц (правда, не таких широких). просто в ряде случаем быстрее получается использовать 1НФ, чем 3НФ.
11 сен 04, 16:38    [952970]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
это уже даже не смешно. 50-100 полей

И ещё, кто-то тут разглагольствовал по поводу "качественной структуры" БД. Так вот, типичные для ФМ системы - CRM, JTS, OTS. Если в результате проектирования JTS у Вас получается структура из 100 таблиц по 1000 полей на таблицу, то ни о каком качестве проектирования здесь говорить не приходится.
11 сен 04, 16:51    [952979]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Действительно... бррррр...
11 сен 04, 16:55    [952981]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
S.G.
Действительно... бррррр...

Что, холодно?
11 сен 04, 17:06    [952983]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
А вообще, странные вы ребята (те кто спорить пытается). Мне, к примеру, никогда не придет в голову на ФМ писать систему биллинга какой-нибудь сотовой сети, а если кто-нибудь возьмется на Оракле писать CRM для компании на 100 человек, я над ним искренне посмеюсь.
11 сен 04, 17:21    [952991]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
автор
а это смотря что делаешь. у меня к примеру есть несколько сааавсем ненормализованных таблиц (правда, не таких широких). просто в ряде случаем быстрее получается использовать 1НФ

Согласен, иногда для повышения производительности надо произвести денормализацию. ну так это в ряде случаев, но не "обычно", как говорил господин Зуев.
Хранить все данные в одной таблице - это подход студента первого курса, выполняющего лабораторную работу.

АЗ
Есть такая контора Schawk, Inc. Крупная, трансконтинентальная препресс компания с офисами в США и Азии

А Вы всё продолжаете нас буржуями пугать: то авторитетными америкосовскими менеджерами, то азиатами какими-то.

АЗ
Так что, если Вы имеете представление о теории реляционных баз данных, то должны вероятно понимать, что сложность РБД зависит от её структуры, а не от кол-ва полей.

ну да, если все данные в одну таблицу запихнуть, то структура бд будет архипростой

АЗ
Так вот, типичные для ФМ системы - CRM, JTS, OTS. Если в результате проектирования JTS у Вас получается структура из 100 таблиц по 1000 полей на таблицу, то ни о каком качестве проектирования здесь говорить не приходится.

это Вы к чему? к тому, что системы, на фм спроектированные, получаются некачественными?
11 сен 04, 17:35    [952998]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
иногда для повышения производительности надо произвести денормализацию. ну так это в ряде случаев, но не "обычно", как говорил господин Зуев.

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



А Вы всё продолжаете нас буржуями пугать

Вам не кажется что Вы как-то предвзято относитесь к моим словам? Я ведь просто описал пример того, насколько сложной может быть таблица, в которой всего 114 полей. Причем, если Вы читаете по английски, я привел комментарий о заказчике, который вовсе не прибавляет им авторитета. Почему же Вы решили что я Вас ими пугаю? У Вас с нервами всё в порядке? Как насчет мнительности? Как можно разработчику Вашего уровня пугаться людей, которые не могут разобраться в таблицы из 114 полей?



АЗ
если все данные в одну таблицу запихнуть, то структура бд будет архипростой

Если Вы хотите сохранить структуру БД, то перенос всех таблиц в одну многократно усложнит систему.



это Вы к чему?

К тому что избыточное кол-во полей это либо ошибка проектирования, либо недостаток СУБД.
11 сен 04, 18:19    [953009]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить