вопрос организации хранилища для разнородных пользователей

[Krishna]

findnext
Не согласен - делай по-своему, непонятно только зачем тут топик создавать.

 

[HraKK]

findnext
Что ты распинаешься? В СНГ есть такое понятие "а вось пронесет" и лень. не однократно уже проходили, когда лень сразу делать по человечески думаю тут сейчас 5 мин сьэкономлю, а потом оказывается что не пронесло и тратят в 5 раз больше времени.

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

 

[findnext]

Krishna это не мой топик


HraKK

Я не настолько богат, чтоб покупать девешвые вещи

+1

 

[Krishna]

А, пардон.

-~{}~ 17.12.08 15:25:

HraKK
При чем тут по-человечески? Может прежде чем говорить для начала стоит немного теорию ORM пожевать? Про реализацию наследования в реляционных структурах, какие они разные есть и зачем они нужны?

-~{}~ 17.12.08 15:28:

http://martinfowler.com/eaaCatalog/singleTableInheritance.html
http://martinfowler.com/eaaCatalog/classTableInheritance.html
http://martinfowler.com/eaaCatalog/concreteTableInheritance.html

 

[HraKK]

Krishna
Изыди.

Мне кажеться я нашел второй ник WP.

 

[findnext]

хехе, перешли на объекто ориентированные бд....да это всё только теория и таких теоретиков много, им только дай повод и они напишут статьи и попытаются доказать что чёрное - это белое...

-~{}~ 17.12.08 16:02:

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

 

[HraKK]

findnext
Там совсем про другое, просто он кидается ссылками не понимая что в них написанно.
Вот он выступает за метод
http://martinfowler.com/eaaCatalog/singleTableInheritance.html
Против
http://martinfowler.com/eaaCatalog/classTableInheritance.html
Совершенно не понимая что где почем.

 

[findnext]

гы, весьма интересный топик получился, от организации самой простой инфосистемы до ORM

 

[HraKK]

кстати причем тут ORM тоже не понятно, но бог с ней.

 

[findnext]

ну надо же как нить выкрутиться

 

[Beavis]

HraKK
а ты всегда проектируешь БД так, чтобы она была нормализованной? и до какой степени?

 

[HraKK]

3-ей атомарной

 

[Beavis]

HraKK
а не было такого, чтобы пожертвовать "правильностью" ради скорости и удобства использования?
(это не относится к данному топику, просто интересно)

 

[x-yuri]

На мой взгляд вариант товарища HraKKа , пожалуй, единственно правильный с точки зрения теории баз данных

но мы же тут обсуждаем практическую проблему? ;-)

полность не согласен, надо думать в перспективе, иначе потом придётся разбивать таблицы и приводить к нормализации 3 степени - а это намного больше гемороя, чем сделать это сразу.

мне очень понравилась фраза Кента Бека, что "каждая методология определяется страхом". Так и здесь - кто-то борется за целостность бд, кто-то боиться изменений, а кто-то - сделать лишнее движение. Надо только выбрать себе страх

 

[findnext]

Beavis

а ты всегда проектируешь БД так, чтобы она была нормализованной? и до какой степени?

я допустим, всегда и до конца

 

[Krishna]

HraKK
Слушай, мне вот просто любопытно, ты серьёзно считаешься, что разбираешься в предмете настолько, чтобы давать советы?
Или ты просто пытаешься авторитетом модератора давить?

Между прочим http://martinfowler.com/eaaCatalog/classTableInheritance.html не имеет отношения к твоим чайниковским советам человека, который узнал о третьей форме и поднял её на свой щит, как единственно верную панацею
Эти решения позволяют работать с базой в виде отношения 1 кортеж = 1 объект. А ты предлагаешь разбить объект на составные. Зачем - а х.з., просто тебе сказали что 3НФ это круто и единственно верно.

У ТС были следущие условия:

У меня в системе есть 3 группы пользователей

То бишь фиксированное число. Причём я уточнил в ответе, что мой вариант подходит именно для фиксированного числа.

в разным набором характеристик. Не знаю как правильно хранить о них информацию. Не хочу создавать три разные таблицы.

Не знаю по каким соображениям не хочет, но моё решение по счастью этого тоже не требует.

У пользователей есть 5 одинаковых поля (ФИО, логин с паролем). Не знаю как лучше сделать. Подскажите как грамотно это сделать?

Так вот, советчик, скажи мне, например, как ты реализуешь полнотекстовый поиск по нескольким полям при твоём варианте. И представляешь ли ты, что будет если кол-во записей будет в сотни тысяч, а запросы достаточно сложными?

Моё решение (на самом деле вовсе не моё оно и не я его придумал) оптимально с точки зрения полнотекстовых индексов и производительности вообще, а так же крайне просто реализуется. При чём, при грамотном составлении запросов можно и поля относительно просто добавлять.

Какие твои плюсы? На каком основании ты считаешь, что ТС не должен слушать другие советы окромя 3 НФ?

-~{}~ 17.12.08 16:38:

+ мне интересно, можешь ли ты привести примеры серьезных продуктов, которые хранят данные о пользователях в том виде, на котором ты тут настаиваешь?

 

[findnext]

Krishna
твои подход предполагает дублировку данных, а следовательно это бд не имеет право на жизнь, чего тут доказывать

 

[x-yuri]

В СНГ есть такое понятие "а вось пронесет" и лень

но ведь лень двигатель прогресса

3НФ: сначала кажется, что это круто (правильно), но потом понимаешь плюсы и недостатки решений и выбираешь исходя из них, а не из того, что круто (что является самым правильным решением), а что нет, ибо http://despair.com/quality.html

-~{}~ 17.12.08 17:14:

твои подход предполагает дублировку данных, а следовательно это бд не имеет право на жизнь, чего тут доказывать

о каком дублировании данных речь идет?

 

[phprus]

HraKK
Полностью нормализованная структура из нескольких таблиц - это конечно мегакруто, но летом я участвовал в одном проекте, где такая структура была отклонена из-за низкой производительности.
Я сразу хочу сказать что запросов я не видел, а видел только результаты тестирования, так вот на примерно 1000000 сущностей имеющих примерно по 15 атрибутов поиск с фильтрацией и сортировкой по атрибутам отрабатывал за минуты, а если очень не повезет(большое количество фильтров), то за десятки минут. БД была на PostgreSQL 8.3. Так как общее количество типов было фиксированным, а добавление новых сущностей не могло не вызвать изменение части кода проекта, было принято решение вынести все общие свойства в основную таблицу, а для каждого типа создать по своей собственной таблице. Типов было примерно 16 штук, а общих атрибутов получилось порядка 5-7.

P.S. Я НЕ говорю, что структура HraKKа не имеет права на жизнь. Это конечно-же не так, НО для того чтобы разрабатывать структуру надо хотя-бы представлять требования к этой структуре, хотя-бы в объеме вопросов, которые задал в этой теме atv.

findnext

твои подход предполагает дублировку данных, а следовательно это бд не имеет право на жизнь, чего тут доказывать

Догмы запрещают дублировать данные? Даже движок этого форума использует денормализацию и дублирование данных типа счетчиков сообщений и прочего что-бы избавится от тяжелых запросов с count(). А разрабатывали его не глупые люди.

 

[MiksIr]

М... а никто не знает форум.. нечто среднее между тупизной php.ru и пафосом phpclub.ru? Ну так, что бы реальные вещи обсуждать, а не бросаться нормализованными формами?