@washer

Помогите чайнику
Пример: "Работник и отдел"
Есть таблица SQL отделов и еще одна таблица SQL работников в которую нужно внести информацию по работнику. На форме в комбобоксе отображаются отделы а в эдит вносится новый работник.
вопрос. как связать эти таблицы или как присвоить свой отдел каждому рабочему чтоб например в отчете
увидеть рабочих и их отделы.

p.s. платформа C++Builder и SQL . Заранне благодарен.

0

@MsGuns

"Джентльментский" для подобной задачи 3 таблицы:
1) Таблица - справочник работников
- PUID: уникальный ид-р записи
- PFAM: фамилия
- PNAME: имя
- PNAM2: отчество
...
2) Таблица - справочник подразделений
- DUID: уникальный ид-р записи
- PDUID: ссылка на DUID подразделения, куда входит данное (NULL для корневых)
- DNAME: наименование подразделения
...
3) Таблица - списочный состав предприятия
- SUID: уникальный ид-р записи
- DUID: ссылка на подразделение
- PUID: ссылка на работника
информация о дате, номере приказа и т.д.

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

ну и много еще чего

Добавлено через 7 минут
Вдогонку. Подобная трехтабличная структура позволяет:
1) Хранить (и изменять соответственно) данные о человеке вне зависимости от того, где он числится
2) Хранить (и изменять соответственно) данные о подразделениях вне зависимости от того, кто в них числится
3) Поддержка иерархической (древовидной) модели, отражающей административной структуру предприятия и возможность гибкого ее изменения.
4) Поддержка "совместителей", что весьма востребовано для многих бюджетных (не только) организаций, т.е. работников, одновременно числящихся на нескольких должностях в нескольких подразделениях.
5) Составлять "удобные" (соответственно быстрые и компактные для клиента) запросы для сервере, а также упрощает и унифицирует разработку бизнес-процессов для бизнес-логики сервера.

Добавлено через 12 минут
Ну и на десерт:
Типичная ошибка новичков в проектировании "базовых" приложений - начинать с "эдитов" и "кобобоксов".
Начинать надо вот как:

1) Исходные требования
Определить кому нужна программа, зачем, как скоро и т.д. Т.е. выяснить может ли "заказчик" обойтись без нее (Например, с помощью Экселя, Ворда и т.д.)

2) Постановка задачи
Изучить предметную область, особо тщательно проработать документооборот, всю "первичку". Составить МОДЕЛЬ ДОКУМЕНТООБОРОТА с подробным пореквизитным описанием каждого.
Определить в общих чертах структуру, объемы, периодичность выходной информации.

3) Определить ОБЪЕКТЫ БД. На основании собранной информации описать объекты реальной жизни, являющиеся предметом хранения и обработки БД.

4) Определить связи между объектами, устранить вторичность (избыточность) информации, проведя ее нормализацию (т.е. фактически определить состав и характер нормативно-справочной части БД), получив в итоге МОДЕЛЬ БАЗЫ ДАННЫХ.

После того, как будет выполнено эти 4 НАЧАЛЬНЫХ этапа проектирования можно приступить к разработке интерфейса пользователя. Опять таки не с комбиков начиная, а со списка функционала, перечней прав, способов установления соединения, типа СУБД и т.д.

В общем, думаю, прежде чем садиться за "прогу", надо все же что-то почитать кроме Архангельского

0

@Grossmeister

На самом деле в простых случаях достаточно 2 таблицы: родительская с подразделениями и дочерняя с сотрудниками, в которой некоторое поле ссылается на подразделения. С ее помощью реализуются все перечисленные пункты кроме "людей, числящихся в нескольких подразделениях"

0

@washer

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

Добавлено через 2 минуты
как имменно это изобразить?

0

@Grossmeister

department (подразделения)
-----------------------------
dep_id -- это PK (Primary Key), т.е. уникальный Id подразделения
dep_name
.... -- здесь могут быть и другие поля

employees (служащие)
-----------
emp_id -- PK служащего
first_name
.....
dep_id -- это FK(Foreign Key), ссылка на dep_id из department (поля не обязательно одноименные)

Это структуры таблиц, которые ты спроектировал и первоначально создал в БД.

А как с этим работать визуально, ты уже продумываешь дальше (вариантов м.б. несколько)

0