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

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

Согласен с Анонимом 11/01/2008 [14:15:30] Магические цифры замаячили и понеслась. Ребята, если вам нужно ТЗ - обратитесь в любую соответствующую службу, которая эти отчеты готовит. а если вам нужна тема для освоения - идите мимо, прямиком к начальству.

Анониму от 11/01/2008 [14:15:30] Возьмите себе погонялу.
А то неясно, как к Вам обращаться.
А также к остальным скептикам.
Давайте не будем дергать мужиков за фалды.
Пусть люди попробуют, кому это мешает?
Не нравится эта тема, найдите другую.
Еще ровным счетом ничего не произошло, а уже хор осуждающих.
У меня сосед взял веник и подмел подъезд, просто так.
Пятеро соседей, плевавших окурки, назвали его мудаком.
Что за страна?

to ЛИНК:

=========
У меня сосед взял веник и подмел подъезд, просто так.
Пятеро соседей, плевавших окурки, назвали его мудаком.
Что за страна?
=========

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

Анониму от 12/01/2008 [11:15:17]

Вы кто? Аноним от 11/01/2008 [14:12:07] или Аноним от 11/01/2008 [14:15:30]

Очевидно, у двух последних позиции радикально разные.
А что касается моей, то ее не видит только не желающий видеть.
Повторяю:НЕ БУДЕМ МЕШАТЬ ЛЮДЯМ, КОТОРЫЕ ХОТЯТ ХОТЬ ЧТО-ТО СДЕЛАТЬ.
Не за деньги, между прочим.
Им этого еще никто не обещал..

to ЛИНК:
Я Аноним от 12/01/2008 [11:15:17].
И хожу сам по себе.

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

----------
Если же по существу темы.
Что за вклад предлагают внести в ТЗ?
Вы то сами поняли?

Умоляю, возьмите ник.
Тем более, что НИК АНОНИМЕН САМ ПО СЕБЕ.
Вас, Анонимов уже трое.
Нельзя ведь каждый раз переспрашивать, кто есть кто.
По существу темы пока никто не высказался, наверное думают.
Тема серьезная.
Кстати, Вы меня повеселили с веником.
Что и откуда Вы знаете про мои дебаты с бычкоcеями?
Но я не хотел бы засорять эту ветку обсуждением участников.
Давайте все-таки о наших баранах.

В бывшей базе было несколько библиотек: библиотечка федеральных округов, субъектов Федерации, мест установок средств, совмещенных объектов, объектов, филиалов, центров ОВД, ныне нужно добавить отделений и т.п. Все х-ки, относящиеся к средству каким-то образом наделялись признаком и при необходимости оно компилировалось из затребованных данных.

2 VV
Вы все время говорите о БД, которая интересна только Вам в силу Ваших должностных обязанностей. Кстати говоря, для программиста легче с нуля что-то написать, чем разобраться в чужом произведении. К тому же ввод исходных данных (и их корректировка)в Вашу БД производится вручную из отчетов. Здесь же предлагается строить Вашу БД, которая сможет автоматически собирать необходимые данные с низовых (локальных)БД, но которые необходимо для этого ЕДИНООБРАЗНО построить.Другими словами, дать всем участникам процесса инструмент, заточенный под общие задачи.Чем не задача для руководящей и направляющей ГК?

"Инженер по РНРЛиС" высказал продуктивную идею - построить БД на WEB-технологии.Локальные БД (или записи общей БД)в этом случае можно хранить на центральном Web-сервере и наполнять (дополнять, изменять) удаленно посредством Интернет.Это решение не исключает разработку приложения по формированию статотчетности для низовых структур, а лишь решает вопрос о синхронизации данных на главном сервере.

Произошло раздвоение темы.
Инженер по РНРЛиС отчитался о проделанной работе на корневой ветке
http://www.forum-avia.ru/forum ...
Где будем продолжать базар?

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

Я так понял хотят построить систему из распределённых баз данных. Так как "автоматически" ни чего не вводится. Идея хорошая. Платформа должна быть СУБД или с примочками от СУБД. Так как приложений собственного и полусобственного плюс с ворованным в компании как правило много.
Но есть один минус. А как всем этим упровлять? Завтра Петров добавит пару полей в свою БД, и Сидоров в отместку удалит пару таблиц уже из своей БД, а Иванов, вообще отключит подключение, так как его выдрал директор.
Так же проблема одним присоединением не ограничится, нужно ведь править данные а не только на них смотреть, а потом звонить через пол страны Петрову что бы он исправил ошибочку.
К тому же могу добавить что нужны специализированные (заточенные под задачу) интерфейсы.

Ну и последнее. Если это делать в Сибири, то вас уволят, так как Вы будете (как говорят новые русские) самым умным и продвинутым, а остальная часть персонала будет работать операторами ПК. А ваша прога будет рости и расширятся, находить косяки. Народ там тёртый, быстро всё смекнёт, и скажет директору что вы лох последний, да и вообще враг компании.

Если решитесь делать, то найдите процессы которые работают с фундаментальными данными. Ну например: на хлебозаводе это хлеб такой то, а дельше сколько муки, людей, других вещей к нему цепляется, в т.ч. и продажи. В авиации это самолёт, тип, бортовой и сирийные номера, двигатели, наработки, рейсы (на рейсы рекомендую повесить продажи и расходы ГСМ, аэропорт, дистанции, карту и т.д.), запчасти и т.д. Это позволит создать вам нормальную реляционную структуру, и избежать избыточности данных. Ну и конечно новомодное бестолковое слово - WorkFlow, поможет вам убедить директора что вы прямо впереди самого что ни есть рубежа прогресса :-).

Желаю удачи.

Раз уж обсуждать данную проблему построения БД более негде(камушек в адрес сайта ГК) - то лучше уж здесь, пока ветка жива. Вкратце о идеологическом построении всей структуры. Web интерфейс для такой задачи - наиболее простое в реализации и эксплуатации решение. Ничего не нужно изобретать, просто выбрать нужный инструментарий. В моем случае - это связка PHP и MySQL (лицензионная чистота данной связки кристальна) - простая и надежная, как АПР-7. Прежде всего это позволит обойтись без системы изматывающих сроков подачи отчетности, так как низовое звено "от сохи", то есть уровень Центра, может планомерно и спокойно осуществлять элементарные манипуляции с данными, а "верхнее звено" может не менее просто эти данные анализировать.
Никаких локальных БД не нужно. Есть единая БД, которая легко управляется стандартными средствами, как любой сайт с формами ввода данных пользователей. БД ведь не состоит из единственной таблицы. Это целый комплекс связанных по различным признакам таблиц. При этом гибкость такой БД безгранична. Пример - любой форум. С сообщениями форума можно проводить практически любые манипуляции: создавать, править, относить к разным тематикам, вести поиск. Точно такой же принцип я попытался заложить и в систему сбора и анализа данных.
Проблема управления? Ее нет как таковой. Разграничение доступа, система привелегий, фиксация действий, резервирование данных, проверка "на лету". Добавлять поля - прерогатива root, а не Петрова. А Сидоров при всем своем желании не может испортить данные Иванова из чувства личной неприязни. Посмотреть - может, испортить - нет. В существующей форме отчетности для пересчета суммарной наработки нужно провести массу ненужных манипуляций с таблицей. Но ведь эту же операцию для всего оборудования Центра можно сделать за час - вбить годовую наработку, пусть машина считает: у нее это получается быстро и безошибочно. Есть и систематические ошибки. Простейший пример - ведущие нули в числовом поле, где хранится заводской номер. При неоднократной трансформации эти нули теряются, из за чего теряется достоверность данных в целом. То есть первочередная задача - это структуризация данных. Конечный пользователь не видит структуру данных, не знает о вычислениях и способах индексации или форматах полей. Ему это и не надо. Реляционная база освобождает пользователя от необходимости понимания физической модели базы, оставляя ему свободу манипуляций с данными. Но связь между разроннеными данными может выстраиваться по самой произвольной цепочке, от простой "Центр-ПРС" до сложной "ПРС-Отказы в первом полугодии 2004 года-Наработка-Назначенный ресурс".

Немного о структуре БД. Для обсуждения: структура таблицы оборудования:
Идентификатор записи.
Идентификатор филиала.
Идентификатор центра.
Идентификатор объекта.
Наименование оборудования.
Идентификатор типа оборудования.
Заводской номер.
Дата выпуска.
Завод-изготовитель.
Дата ввода в эксплуатацию.
Дата окончания назначенного ресурса.
Фактическая наработка.
Идентификатор сертификата типа.
Данные о заполнении поля(кто, когда внес данные)
С данной таблицей связываются другие: например, таблица учета отказов, таблица контрактов на поставку и ремонт, таблица приобретения ЗИП, таблица плановых замен. Какие поля в таблицу оборудования необходимо добавить?

2 Инженер по РНРЛиС:
Изложение в форме коммента к Вашим постам.
Поехали!
1.Камешек в адрес сайта ГК заслужен ГК. Там живое обсуждение невозможно из-за отсутствия обсуждателей. Да и генетическая память о недремлющем оке сковывает фантазию и морозит язык. Лучше общую концепцию отточить здесь, а туда (на сайт ГК) перебраться при тестировании версий. Рано или поздно информацию к размышлению придется излагать в виде форм и таблиц, а здесь это невозможно.
2.Полностью согласен с идеологией единой базы данных. Опыт работы с локальной самопальной базой в службе ЭРТОС (MS ACCESS) с использованием репликации быстро учит жить.
3. Формат поля для хранения заводского номера вроде бы должен быть текстовый, тогда нули не помеха. У некоторых изделий в состав серийного номера входят буквы.
4. Согласен, архиважнейшая стартовая задача- определение объема и структуризация данных. Предлагаю в качестве идентификатора записи использовать инвентарный номер по балансовому учету. Это позволит нащупать связь с 1с Бухгалтерия, что очень важно при операциях с драгметаллами, аммортизацией (генетически связанной со сроком службы) и пр. Вот если еще в структуру инвентарного номера были бы заложены данные о филиале, центре......
5.Вижу проблему с идентификацией объекта. Особенно, если изделие РТО и связи не локатор, а ДПУ ОРЕХ на ВСДП аэродрома или мультиплексор на КДП. Даже в самой службе ЭРТОС понятие ОБЪЕКТ трактуется как бог на душу положит. Загляните в ФАП. Оборудование на КДП есть, а объекта КДП нет. Как в жизни: Ж... есть, а легитимного ( употребляемого без краски стеснения) слова Ж... нет.
6. По фактической наработке. Умоляю не мельчить и в первичных формах ввода ограничиться годовой наработкой. Люди уже изнасилованы ежемесячным заполнением наработки в формуляры изделий. Абсолютно вредное занятие. Мне кажется, что значение наработки и связанный с ним показатель надежности- наработка на отказ сходит на нет. Моральное старение техники происходит быстрее ее физического износа.
7.Сейчас покатятся предложения о включении в состав данных того, сего ..... Думаю, при обсуждении надо сразу включить жесткий фильтр крайней необходимости и добавлять поля по ходу тестирования начальных версий, чтобы не зарыться в деталях.

2 VV (как заинтересованному лицу в создании БД для ГК):
Предложенная здесь концепция создания централизованной БД по средствам РТО и связи предполагает наличие центрального сервера БД на основе Web-сервера и соответственно наличие администратора этой БД на постоянной основе.
Готова ли IT-структура ГК взять на себя эти обязанности?

2 Инженер по РНРЛиС:
Понятно, что единая БД - "яйца в одной корзине". По этой причине (или другой - например, при отсутствии в какой-то момент времени доступа в Интернет), думаю, удаленые пользователи такой БД(они же и ее создатели) захотят иметь у себя копию своего фрагмента из общей БД (что по сути эта копия и есть "локальная" БД) для текущих нужд.
Возможно ли получить такой фрагмент в виде файла (стандартизированного формата), с которым могли бы работать известные офисные приложения?

Продолжаем обсуждение.
2БЫВАЛЫЙ
1. Пусть ГК сама разгребает камни со своего огорода. Наше дело давать им реальные советы, их дело пока ограничивается надуванием щек. Извиняюсь за резкость.
2. Согласен, MS ACCESS и локальные базы - зло. Но к сожалению, еще хуже, когда из Excel гоняют данные в ACCESS и обратно. Видимо, сказывается проблема незнания эффективного инструментария.
3. В предлагаемой мной таблице формат заводского номера - текстовый, ограничен 15 символами.
4. Идентификатор - это средство внутренней обработки, служебная информация, которую пользователь не видит и не может изменить. Инвентарный номер в качестве самостоятельного поля добавить можно, но при этом есть риск, что он не будет уникален для разных филиалов. Поэтому его нельзя использовать в качестве полноценного индекса.
5. Идентификация объектов - согласно его полному наименованию. Физически это цифра, ссылка на индекс в отдельной таблице-перечне объектов. Машине так проще. Для человека выводится полное наименование объекта. Если средство стоит на ВСДП - так оно и будет записано, причем ВСДП в пулково и Кольцово - это два разных объекта. Для сертифицируемых объектов - наименование по сертификату.
6. Фактическая наработка заполняется раз в год, по умолчанию представляется возможность указать 8760 часов. Заполнение данных в объеме Центра - примерно 30-40 минут при наличии исходных данных с объектов.
7. Фильтр - разумная достаточность. Например, включить номер разрешения для радиопередающих средств не видится излишним, а вот указание рабочих частот для Баклана избыточно, хотя при необходимости через идентификаторы стредств (технические параметры) и таблиц радиочастот можно построить требуемый запрос.


2Helper
Запросы из MySQL экспортируются в любые форматы, например txt, html, xml, mdb, dbf, pdf, rtf, csv или xls.

После чтения ветки создалось впечатление что студенты изучают реляционные базы данных. :)))

2 Инженер по РНРЛиС

Идентификация объектов - согласно его полному наименованию. Физически это цифра, ссылка на индекс в отдельной таблице-перечне объектов. Машине так проще. Для человека выводится полное наименование объекта. Если средство стоит на ВСДП - так оно и будет записано, причем ВСДП в пулково и Кольцово - это два разных объекта. Для сертифицируемых объектов - наименование по сертификату.

1.Если БД общая на Россию, то каков объем таблицы-перечня объектов и кто ее будет набивать?
2. Все таки инвентарный номер привлекателен для использования.По данным нашей бухгалтерии в начале номера имеется уникальная для центра ОВД цифра. Может быть есть в номере и межфилиальная классификация?

2 Анониму от 16/01/2008 [13:08:04]
Здесь уже далеко не студенты. Продолжаются традиции эртосников.
Надо к утру реляционные базы - сделаем Вам базы.
Это из серии копать, паять, бетонировать..........

2БЫВАЛЫЙ:
Данные по средствам - из расчета около 1к на средство. То есть не более 15-20Мб. Первоначально данные по средствам должны набиваться центрами. Но это разовая работа.
Индексирование по 9-значному инвентарному номеру (возможно, и не 9-значному, а более) создаст лишнюю нагрузку и снизит общую скорость работы. Если нужно создать выборку, например, по инвентарным номерам в заданном диапазоне - это совсем другое дело. Но индекс и критерий выборки не всегда одно и то же.

2Аноним 16/01/2008 [13:08:04]:
Есть реальные предложения? Нет? Проходите мимо, не задерживатесь.

2 Инженер по РНРЛиС:
Уточняю свою непонятку.
При идентификации объектов необходимо кому-то набить таблицу с названиями этих
объектов.
В предыдущих постах объекты предлагалось именовать не унифицированным образом, а по сложившимся обстоятельствам.
ВСДП ПУЛКОВО, ВСДП КОЛЬЦОВО, КУНГ ВОЗЛЕ ЗДАНИЯ ВОХР УРЮПИНСКА,
ЛАЗ СВЯЗИ МЕЖДУГОРОДКИ НЬЮ-ЙОРКА, ОСТАНКИНСКАЯ ТЕЛЕБАШНЯ (а что, у нас ФАЗАНЫ на мачтах Ростелекома) И Т.Д.
Собиратели отчетов в ГК попросят дать в разрезах по аэропортам, забывая о том что в России масса отдельно стоящих позиций, вынесенных ретрансляторов и т.п.
Я это к тому, что идентификация по объектам в лучшем случае затруднительна.
Ваша точка зрения?

Считаю, что название объектов надо давать в привычной форме - ВСДП, ОРЛ-Т, КРМ совмещенный с БПРМ и так далее, чтобы не вносить путаницу. А для определения местоположения объекта указывать ближайший населенный пункт или аэропорт (если в населенном пункте несколько аэропортов). Разумеется, привязывать, например, ОРЛ-Т к аэропорту лишено смысла. Для более точного указаная местоположение предусмотрено указание географических координат.
Данные в таблицы вносятся распределенно. То есть, Центр (Филиал) указывает список объектов, который при необходимости может изменяться. А уже в таблицу средств вносятся данные на основании перечня объектов Центра из выпадающего списка. Сама по себе идентификация по объектам и попытки привести ее к стандартной форме бессмысленна: есть совмещенные объекты, в разных регионах своя традиция наименования несертифицируемых объектов. Но привязка к объектам нужна, так как при этом решаются вопросы, связанные с эксплуатацией именно объектов - сертификация, электроснабжение, тем более в базе можно хранить любые данные, вплоть до Паспортов, Актов техсостояния, актов отказов. Потому что помимо сбора сведений, грамоно сконфигурированная база позволит избавиться от массы рутинной работы по отчетности, статистике и планированию. несомненно, первоначально данные надо быдет потрудиться ввести, но уже буквально при составлении ближайшего полугодового отчета многие вещи не надо будет переправлять по электрической почте или на посыльных голубях.

2 Инженер по РНРЛиС:
ЕЩЕ ТРИ СПОРНЫХ МОМЕНТА
1. ГЛУБИНА ОХВАТА И ДЕТАЛИЗАЦИЯ СРЕДСТВ РТОП И СВЯЗИ. Предположим, мы хотим описать в системе БПРМ.
Объект -БПРМ и на нем установлены ПАР-10+МРМ+Р-407. Все они имеют оформленные раздельные разрешения на радиочастоты. По бухгалтерии числятся единым объектом бухучета ОСП-7 с однажды определенным сроком службы (полезного использования). Т.е. один инвентарный номер на весь ОСП-7. Ответная часть Р-407 установлена на КДП и должна числиться в составе средств другого объекта (КДП). И таких случаев много, когда часть РТОП, установленного на одном объекте и закремпленного за ним, монитруется на другом объекте. Это касается всего выносного оборудования, РРЛ, распределенных СКРС (систем речевой связи)......
2. Второй вопрос, стоит ли мельчить и описывать в системе модемы, мультиплексоры, маршрутизаторы, персоналки и прочую чешую, которая плодится не хуже тараканов. Это вопрос к корпорации. Она заказывает музыку.
3. Третий вопрос плавно вытекает из второго и касается Вашего утверждения "Пусть ГК сама разгребает камни со своего огорода. Наше дело давать им реальные советы, их дело пока ограничивается надуванием щек."
По моему мнению, так дело не пойдет. Единственного разговорчивого представителя ГК на ветке, не самого высокого ранга, но все-же переживающего за дело, как ветром сдуло. Наверное обиделся.
Без деятельного участия ГК затея провалится. Я даже не говорю о том, что БД надо администрировать на постоянной основе. Точка зрения ГК должна быть отражена в самом проекте БД.

2БЫВАЛЫЙ
1-2. Вот как раз и пример, что нежелательно вести индексацию по инвентарным номерам(ОСП-7). В данном случае наверное есть смысл ввести именно отдельно ПАР-10+МРМ-70+Р-407(полукомплект). Кстати, в бухгалтерии есть еще особенность - там люди далекие от техники, нередко в названиях средств встречаются ошибки. Мельчить конечно не надо, переписывать вплоть до последнего монитора смысла нет. Но тот же мультиплексор в силу своей ответственной функции хоть и не является основным оборудованием на том же КДП, но будет в базе не лишним. Хотя вот, к примеру, учет средств измерения без привязки к объектам был бы нелишним, по крайней мере у нас ситуация со средствами измерения сложная - новые приборы очень недешевы, а старый парк сильно изношен и не всегда проходит поверку.
3. Похоже ГК глубоко параллельны эти проблемы. Тут же возникает вопрос: стоит ли дальше вообще этим заниматься, или плюнуть и забыть? При наличии желания можно полностью все оформить, найти сервер для хранения данных, но вот есть ли смысл развивать эту идею? Убедившись в полной работоспособности, писать дальнейшее развитие для "корзины" не очень хочется. Либо ГК незаинтересована в создании более-менее стройной и работоспособной системы учета, либо ГК просто не владеет информацией о состоянии дел. Ждем реального ответа от представителя ГК.

2 Инженер по РНРЛиС:
Как это ни смешно, но факт.
Известный нам на ветке " представитель ГК " еще месяц не
будет способен продолжить обсуждение.
Вся энергия будет направлена на переваривание поступивших отчетов.
Мои искренние сочувствия вбивателям ручным способом в базу данных ГК , поступивших
с мест в Excell формате сведений об РТО.
Думаю, что надо самим выйти на контакт с отделом информационных технологий ГК с предложением рассмотреть вопрос размещения сервера БД на ресурсах ГК.
Может быть и там есть энтузиасты?
Попробую дозвониться.

Реплекации в Аксессе - это конец любого начинания.
Это точно.

А вообще ситуация с построением БД \ ИС в конторе, это как ни странно вопрос политический. Если боссам пофигу, и дают только одно - хочу. Лучше не тратить время и силы.
Поэтому вопрос автору ветки - А надо эту ИС делать?

2+1
Эта и не только эта ИС (БД) нужна прежде всего нам.
Достала бумажная возня.
А начальники получают инфу уже в виде готовых таблиц,
им парится не надо.
Да и скучно жить без свежака.

Да, друзья, эк вас как торкнуло.
Какие слова: СУБД, Web, ...Запросы из MySQL экспортируются в любые форматы, например txt, html, xml, mdb, dbf, pdf, rtf, csv или xls....Реплекации в Аксессе...

Уже все решили?

А вы не думали, что сначала нужно написать хотя бы ТЗ, где вы сначала осуществите постановку задачи, сбор исходных данных, обоснуете или нет необходимость НИР, обоснуете целесообразность применение ранее разработанных программ и пр..., без которого (ТЗ) дальнейшее продвижение просто абсурдно.
Почитайте ГОСТ ЕСПД, увлекательное, знаете ли, чтиво!

Почитайте ГОСТ ЕСПД, увлекательное, знаете ли, чтиво!

По вопросам проектирования БД ну очень много литературы. И нормативной и технологической, не говоря уже об учебной. Но велосипед изобрести очень хочется! :))

А Вы уверены что нужен именно велосипед?

А Вы уверены что нужен именно велосипед?

Это обсуждение ну очень на это похоже! :))

Аноним от 22/01/2008 [08:37:06] и Аноним от 22/01/2008 [09:28:03]- ЭТО НАДО ДУМАТЬ РАЗНЫЕ АНОНИМЫ? Ну сколько можно говорить, неужели трудно взять ник?
Особенно, если расчитываете на ответ.

Теперь по сути замечания: " Почитайте ГОСТ ЕСПД, увлекательное,
знаете ли, чтиво!"
Автор этого нравоучения, несомненно, его читал. Ну и какой мне лично от этого прок?
Базар ведь не о том, чтобы продемонстрировать на весь мир свою осведомленность (хотел сказать гениальность).
Профессионального обсуждения на ветке практически нет и быть не может. Это удел профи. Есть только пожелания замордованных пользователей и ОДИН герой нашего времени "Инженер по РНРЛиС", который заявил I KNOW HOW!!!
Если правда умеет-заслужит благодарность и может быть денежку заработает, а нет - опозорится.
А лично мне наплевать, читал ли он ГОСТ или сам дотумкал.
Проблема ведь в том, что наши начальники этот ГОСТ уже который год никак не дочитают до конца. Видимо, на самом деле увлекательное чтиво.
А народ стонет от бумагоделательной технологии. И это в 21 веке.

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

БЫВАЛЫЙ:
База данных это не палатка с фруктами. Переделать криво сделанное сложнее чем сделать заново.
Вопрос первый. Кому нужна единая база данных? Госплана уже нет. Единой бухгалтерии практически тоже.
Вопрос второй. Кто определит иерархию этой базы? Не понимаю, зачем в Москве знать точную марку и прочие данные о телефонном аппарате где то в Васюках?
И таких вопросов может быть много.
ПыСы. Ответа не прошу. Это просто мои мысли по поводу...

2 Анониму от 22/01/2008 [11:29:00]
Мы молимся разным богам.
Вы красоте и совершенству лопаты, а я ее полезности.
Насчет телефонов и Васюков.
Если отчетность волокут в Москву из Васюков, значит она кому-то нужна.
Если зашли на ветку и смыслите в теме, а это видно, поделитесь
позитивом.
А так, мысли вслух - для чего?

to БЫВАЛЫЙ:

В своем посте от 22/01/2008 [10:47:59] Вы очень тонко подметили одну деталь: "...Есть только пожелания замордованных пользователей

Так вот мой пост был именно о том, что большинство пустозвоном от ИТ, чуть-чуть разобравшись с Аксессом, уже определяют форматы, языки, протоколы и прочее для будущей системы, и даже не удосужились понять ЧТО НУЖНО СДЕЛАТЬ и ДЛЯ ЧЕГО, по тому как вопрос КАК вытекает из ответов на два предыдущих.

БЫВАЛЫЙ:
Если отчетность волокут в Москву из Васюков, значит она кому-то нужна.

Поверьте, очень редко. Скорее всего на случай, а вдруг Александр Васильевич спросит!))))
Помню как лет десять назад я в 37 доме долго убеждал в необходимости перехода на электронную базу данных. Целый год твердили, зачем она нужна, только лишняя работа по забивке в нее данных. Правда после удивлялись, как оказывается без нее сложнее работать было, ведь вытащить из БД информацию практически щелчок мыши. Но сменился персонал и снова все новое это хорошо забытое старое.

Анонимам.
А чой то вы зашевелились?
Расскажу притчу. В давние, давние времена куча умных, образованных людей думали над проблемой повышения несущей способности бетонных конструкций. Ну не работал бетон на растяжение, хоть тресни. Два изобретателя, строители Куанье и Уилкинсон запатентовали способ повышения несущей способности бетона с помощью металлической арматуры. Но профессиональные строители отлично понимали, что бетон и железо имеют разные коэффициэнты температурного расширения и из-за этого железобетонные конструкции будет разрывать при перепадах температуры, а железо будет быстро ржаветь в пористом бетоне. Садовник Монье мучался с бетонными кадками, которые крошились при транспортировке. Так как он не знал о разнице в коэффициэнтах теплового расширения бетона и железа, он взял да и обмазал металлическую решетку бетоном. И эта конструкция не только не лопнула, но и оказалась значительно крепче обычной. Так и появился железобетон. К чему это я? Титаник был построен профессионалами, а ковчег построили любители. Изучайте ЕСПД, это удел настоящих профессионалов. Я прекрасно понимаю некоторых господ анонимов. Готовое ТЗ, содержащее фактически все алгоритмы - лакомый кусок, не так ли? Обозвать это каким нибудь красивым словосочетанием и потом доить пару лет.

Инженер по РНРЛиС:
Готовое ТЗ, содержащее фактически все алгоритмы - лакомый кусок, не так ли?

Только для тех, кто хочет на этом заработать. Я - нет.
Один раз Вы со мной уже по этому вопросу соглашались. (Согласен с Анонимом 11/01/2008 [14:15:30]).

Ну вы бы как то по номерам чтоли распределились, Аноним №1, Аноним №2 и так далее. Если хотите оставаться инкогнито - залазьте через публичные прокси.

Маленькая ремарка: грамотное ТЗ никогда не навязывает разработчику пути решения поставленных в нем задач.Это даже не этично.

Инженер по РНРЛиС:
залазьте через публичные прокси.

Пару раз попробовал, оказалось что забанены на 10 лет.
Смысла в нумерации не вижу, читайте сами посты, какая разница кто их написал?

Анониму от 22/01/2008 [16:28:19]

"Смысла в нумерации не вижу, читайте сами посты, какая разница кто их написал?"

Вот в этой фразе как в капле воды видна проблема.
И, как всегда, она не в сортирах (читай БД), а в головах.
Если рассматривать эту микроветку как кусочек некоей информационной системы, то режет глаз и слух противоречие.
Одни хотят упорядочить информационный поток, сделать набор кириллицы на экране удобным для использования, другие не видят разницы в способе изложения.
Не хотелось бы превратиться в клуб пикейных жилетов, слышащих только себя.
В обществе, которое всем нравится, принято себя называть (хотя бы псевдонимом),
иначе клуб по интересам превращается в базарную толпу с нулевыми перспективами на результат.
Я ХОЧУ СДЕЛАТЬ СВОЮ РАБОТУ УДОБНОЙ И ПОДАМ РУКУ ЛЮБОМУ, КТО МНЕ В ЭТОМ ПОМОЖЕТ.
ДАЖЕ, ЕСЛИ ОН, ПРОСТИ ГОСПОДИ, НЕ ЧИТАЛ ЕСПД.
Извиняюсь за менторский тон, но Something has to be done.

БЫВАЛЫЙ: 18/01/2008 [08:35:52]
Не сдуло, командировка. Сбросил ссылку на ветку ККК.
Не все так просто с такой БД, по некоторым документам доступ к ней должен быть весьма и весьма ограниченным

2 vv: Разграничение прав доступа - меньшая из проблем. Кто то видит данные в объеме Центра, кто то - в объеме филиала, кто то вообще может только вбивать цифры. А за тем, чтобы базу не стянули с сервера должен следить посадцкий человек - админ.

2 vv
Ограничение доступа к определенной информации в БД является лишь одним из требований к ней, но не препятствием создания БД.Кто-то внятно может сформулировать требования к информационной безопасности предполагаемой БД?

БЫВАЛЫЙ:

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

Извините, но лично я считаю этот форум не клубом по интересам (не тянет!), а что то вроде общественной околоавиационной курилки при авиационном портале авиа.ру. При входе в общественную курилку представляться не принято. :)))
Так что правила приличия и поведения в общественных местах соблюдены. :))