Нормальна ли такая нормализация РБД?

Дошло. А зачем в таком случае таблица users?

Alipapa добавил 12.12.2008 в 01:00

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

Alipapa добавил 12.12.2008 в 04:15

И еще. Юзер может принадлежать одновременно нескольким группам и 1-1 может легко стать 1-много. Поэтому можно считать, что до 3-го уровня у вас нормализовано.

Кстати, спасибо за подсказку, сделаю ещё одну таблицу для хранения групп пользователей :)

prometex добавил 12.12.2008 в 14:13

Я ошибался, в моём случае имеет место наследование, а не связь 1:1

1. Для этого у меня есть таблица типов (на её основе можно строить фильтры например)

типы могут быть назначены для группы или для определенного пользователя, для чего угодно.

Все связи хранятся в таблице связей.

2. и далее хранение данных, грубо говоря id, type, double, text

т.е. если это будет зарплата, степуха, успеваемость, оценка, колво на складе или дата, время то они пойдут в double иначе в текст, ну проверка естесно не по названию типа =)

Turtle_Fly, не могли бы Вы подробно описать эту схему (таблицы, поля, связи)?

Users:

id, имя, пароль

Category:

id, имя категории,

Types:

id, название типа, ну и еще можно добавить поле Единицы измерения или еще что

Data:

id, ссылка на тип, integer (double), text (text)

Ну а далее, либо в каждой таблице добавлять ссылки на другие таблицы, ну например из таблицы Users сслыка на Категорию, или наоборот в Категории добавить поле и хранить там ссылки на пользователей и т.п. ....

Либо сделать таблицу связей:

id, item_id1, item_type1(грубо говоря это название таблицы), item_id2, item_type2

Т.е. получается что во всех таблицах хранятся данные которые никак не связанны м-ду собой (кроме таблицы Data Где есть указатель на тип), а вот за хранение этих связей отвечает отдельная таблица.

Надеюсь смысл понятен =)

еще как вариант сделать таблицу параметров групп

user_id,group_id,param,value

1,1,zarplaza,120

2,1,zarplata,300

3,2,stependia,500

=) может вам так будет удобнее ) чем создавать тонны таблиц )

тогда одним запросом выбираете массив параметров для группы и юзера в группе

Turtle_Fly,

Интересная схема, спасибо, попробую реализовать. Но уже понятно, что если использовать только основные 17 типов данных, то при вставке одной записи в таблицу данных будет заполнено только одно поле, остальные 16 будут NULL, что не совсем рационально.

greyhard, у Вас поле value будет одного типа, а данные разных.

prometex, Можно с самого начала???? Какое количество пользователей ожидается???? Если речь идет о 2-5 тыс, то не насилуйте SQL, есть более быстрые и гибкие способы хранения таких данных, основанных на хешах/ассоциативных массивах.

T.R.O.N, большое количество (10-100к). Что это за способы?

не верно =) разве в этих 2х полях нельзя хранить все типы?

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

но в остальном в double или text поле можно поместить все что угодно хоть timestamp но в другом виде, не Y:m:d H:m а число секунд от Начала =)