Форум PHP

Допустим есть база по персоналу фирмы в ней более 1000 сотрудников
в этой базе анкетные данные ФИО пол прописка ДОЛЖНОСТЬ.
Все это можно уместить в одной таблицы (вроде бы),
но ... в фирме 10 "уборщиц" 700 "оперторов" 20 "инжинеров" ...
и помоему в основной таблице нерационально писать в строке
ВАСЯ ИВАНОВ ... ОПЕРАТОР
ПЕТЯ ЗИНИН ... ОПЕРАТОР

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

ПРАВ ли Я в плане скорости и следует ли такое делать ?

Напишите парочку "хороших" "тонов" написания базы данных
что делать желательно а что только навредит?

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

1 ОПЕРАТОР 2 ИНЖЕНЕР ...

Первичный ключ этой таблицы (1,2..) будет типа INT и являтся вторичным ключом основной таблицы

1 ВАСЯ ИВАНОВ 1 2 ПЕТЯ ЗИНИН 1

Многотабличные запросы в большинстве случае выполняются дольше, но это не тот случай, так как таблица должностей мала и вряд ли будет содержать больше 10 записей (следует опасаться частых 3-4 табличных запросов).
Если использовать одну таблицу, то скорость может падать действительно из-за большего объема самой таблицы и при выборках в условии WHERE, которых имеются условия связанные с полем должности, так как поиск будет производится не по целочисленному столбцу (который к тому же можно проиндексировать), а по строковму.

Кстати, "хорошим тоном" здесь было бы использование 2-х таблиц так как 1000 записей для современных машин это ничто, а время заполнения, сопровождения, а следовательно и стоимость однотабличной базы возрастает.
Оптимизация скорости (с денормализацией базы данных - дублирование данных или объединение таблиц) должна начинаться при реальной необходимости, когда имеющиеся ресурсы не справляются с задачей - SQL легко позволяет модернизировать базу данных на любом этапе проектирования.
К "хорошему тону" относится так же повсеместное использование целочисленных столбцов вместо строковых. Т.е. если вы всё-таки будет реализовывать однотабличный вариант, то для должности лучше использовать тип ENUM, позволяющий опереировать строковыми величинами, но по своей природе являющийся целочисленным.