Ищется программист для разработки "с нуля" или настройки какого-нибудь продукта (типа 1с).
Приблизительное ТЗ имеется.

приблизительное ТЗ

OFF

А 1С надо будет устанавливать?
"на перевалочной(складской) базе" напомнило недавнее "вагоноремонтное депо". Ничего личного.
Извините.

нет не надо. Про депо не ко мне...

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

как всегда вопросов в таких задачах два
1. время реализации и сумма вознаграждения
2. изменение "ТЗ" в процессе работы...

На второй вопрос есть однозначный ответ - ТЗ будет изменено. Так как то, что выложено - еще совсем даже не ТЗ, а просто наброски хотелок.

хммммм....

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

Дело вот в чем. Сейчас программы пишутся с документации. Это значит если вы действительно можете формализовать все параметры и описать все процессы и связи, то вы можете программировать. Если не можете, надо искать специалиста который это может.

Аттач посмотрел, это вообще-то плоская таблица. Где связи?

Предикат баз данных: факт хранится в одном месте.

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

Совершенно не обязательно владеть языком программирования для общего проектирования реляционной базы данных. По проекту любой программист переведет документацию на SQL.

А вот творческий процесс объяснения программисту особенностей перевалки товаров может потребовать очень много водки.Он же понимает в SQL, но ничего не понимает в логистике, и соответственно наоборот. Придется его сначала обучить всему что вы знаете о своей работе.

Ладно вам.. Поставить задачу вменяемому программисту - вечер-два под коньяк.Не такая уж сложная эта логистика. Вы, видимо, с медициной не сталкивались - вот там водки правда много надо.

Не такая уж сложная эта логистика.

Нда...
Логистика, она очень разной бывает...

Это как с переводом с языка на язык. Вы написали справку, хотите перевести ее на английский, например. Чтобы проверить нанимаете читателя-носителя английского. Он вычитывает: ну что, все правильно, все по-английски. Начинаете продавать и оказывается ваши клиенты не понимают что написано английским языком. Потому что редактор знал английский, но не ничего не знал из той области, для применения в которой написана ваша программа.

Автору вопроса еще можно посоветовать забить на АРМ и АСУТП вообще. Дело вовсе не в технике, а в людях. В соседней теме вы можете убедиться в том, насколько быстро разобьются любые блестящие технические решения об отсутствие культуры делопроизводства.

Вера в спасение через компы сильна. Кажется что сейчас вот построю такую удобную систему и все радостно кинутся ей пользоваться и будут поддерживать процессы на высоком уровне. Хрень собачья. Если люди не поддерживают сейчас, они и потом этого делать не станут. Автоматизироваться имеет смысл когда механизм удалось хорошо отладить что называется вручную. То есть когда автоматизация становится потребностью.

Сначала люди, потом компы. А можно наоборот? Можно, но люди вперед.

Чтобы дело не казалось таким простым, напомню что федеральные паспортные и транспортные базы появились совсем недавно. До этого базы были локальными и приходилось делать запрос через оператора базы в другом городе. Из-за чего, например, нельзя было зарегить автомобиль по месту проживания. Совсем свежая новость по базам: трудовая база наконец-то заработала. Теперь трудовые книжки не надо выдавать и поддерживать.

Сколько понадобилось время на проектирование этих баз считая с БЭСМ?

К чему сей опус то? Автоматизировать бардак невозможно - это всем давно известно. Пример с переводом вообще не в тему. Если четко описаны все бизнес-процессы, то плевать на область автоматизации. Так же есть еще понятие цели автоматизации. Если ясных целей нет - снова получается бардак.
Про базы паспортных столов - бред сивой кобылы. ИМХО, вы не в теме.

И насколько четко они прописаны в приложенном ТЗ? Или может быть это программист должен прописать выпив несколько литров коньяку, или что там грузят.

В том и дело что бардак поддается автоматизации не хуже любого порядка. Просто он так и остается бардаком, или даже усугубляется.