|
|
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Всем привет! С проектированием БД несилен только учусь, по этому подхожу к архетектуре базы с точки зрения ООП. В БД должно присудствовать множество однотипных таблиц, типа CREATE TABLE [Parent]( [nIdParent] [int] IDENTITY(1,1) NOT NULL, [strName] [nvarchar](15) NOT NULL) Правильно ли будет сделать 1 общую таблицу этого типа, а все остальные будут иметь вид CREATE TABLE [Child]( [nIdChild] [int] IDENTITY(1,1) NOT NULL, [nIdParent] [int] NOT NULL) Уместенл такой подход, чем это грозит, или же плодить таблицы подобные первой? Спасибо за рание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2009, 21:57 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Судя по словам "Parent" и "Child" вы собираетесь делать древовидную структуру. Для этого не надо плодить таблиц, достаточно одной таблицы, плюс еще прочитать про построение таких структур в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2009, 22:59 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
S.G.Судя по словам "Parent" и "Child" вы собираетесь делать древовидную структуру. Для этого не надо плодить таблиц, достаточно одной таблицы, плюс еще прочитать про построение таких структур в БД. Я бы сказал что это "Наследование", ну вот к примеру есть 15-17 справочных таблиц, содержащие в себе только наименование, есть ли смысл создавать 15-17 таблиц в БД, с одинаковыми полями? или же всетаки существует какой другой/корректный способ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2009, 23:21 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
NahelЯ бы сказал что это "Наследование", ну вот к примеру есть 15-17 справочных таблиц, содержащие в себе только наименование, есть ли смысл создавать 15-17 таблиц в БД, с одинаковыми полями?А почему нет ? Боитесь ограничения на количество таблиц в БД ? Во всех вменяемых СУБД такой предел лежит далеко за гранью практического применения.Nahelили же всетаки существует какой другой/корректный способ?А это уже надо бы более точно описывать исходную задачу, а не предполагаемый Вами способ её решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 00:01 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Nahel wrote: > С проектированием БД несилен только учусь, по этому подхожу к > архетектуре базы с точки зрения ООП. > В БД должно присудствовать множество однотипных таблиц, типа > > CREATE TABLE [Parent]( Если ты в проектировании БД не силён, то зачем тогда формулировать свою задачу в терминах проектирования БД ? Ты по-русски, по простому скажи. Что значит "в БД должно присудствовать множество однотипных таблиц, типа" ? В БД вообще НИЧЕГО не обязано присутствовать. БД данные должна хранить, а как - это уже её дело. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 00:42 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
ChAА почему нет ? Боитесь ограничения на количество таблиц в БД ? Во всех вменяемых СУБД такой предел лежит далеко за гранью практического применения. Нет страх тут не причом, ищу более рациональное решение. ChAА это уже надо бы более точно описывать исходную задачу, а не предполагаемый Вами способ её решения. MasterZiv Ты по-русски, по простому скажи. Есть справочная иформация Материалы Объекты Типы Свойства И таких справочников около 20, в каждом из них только одно значение Название/наименование, и в каждом из справочнике не более 50 записей. Вопрос, правельнее будет сделать отдельную таблицу для каждого справочника или же есть более рациональный способ. Сахават ЮсифовNahel, пшел дурак ахуительно прагматично, шлобы ты само на йух ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 08:41 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Nahel wrote: > Есть справочная иформация > Материалы > Объекты > Типы > Свойства > И таких справочников около 20, в каждом из них только одно значение > Название/наименование, и в каждом из справочнике не более 50 записей. > Вопрос, правельнее будет сделать отдельную таблицу для каждого > справочника или же есть более рациональный способ. Я немного понял, но если у тебя есть 10 таблиц с ровно одинаковой структурой, то надо их делат одной таблицей. Возможно, добавив ещё одно поле -- тип сущности -- в первичный ключ. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 12:07 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Nahel Сахават ЮсифовNahel, пшел дурак ахуительно прагматично, шлобы ты само на йух оно с оного и не слезает По теме топика: если юзаешь sql server 2008, то в нем появился тип hierarchyid . Вполне возможно, что захочешь заюзать его (как вариант, помимо стандартного, предложенного выше S.G.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 12:29 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
NahelChAА почему нет ? Боитесь ограничения на количество таблиц в БД ? Во всех вменяемых СУБД такой предел лежит далеко за гранью практического применения. Нет страх тут не причом, ищу более рациональное решение.Я вот не вижу причин сливать все справочники в одну таблицу, имхо. Конечно, если можно выстроить иерархию справочных данных - то другое дело. Пусть будет 40 таблиц, да хоть 100 - что тут страшного? А вот если множество справочников "запихнуть" в одну таблицу, то можно с ростом объемов данных и тормоза получить при выборках типа Код: plaintext 1. 2. 3. 4. MasterZivВозможно, добавив ещё одно поле -- тип сущности -- в первичный ключ. Не все СУБД поддерживают FK, ссылающиеся на составные PK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 12:44 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
NahelЕсть справочная иформация Материалы Объекты Типы Свойства И таких справочников около 20, в каждом из них только одно значение Название/наименование, и в каждом из справочнике не более 50 записей. Вопрос, правельнее будет сделать отдельную таблицу для каждого справочника или же есть более рациональный способ. Очень неуверен, что таблицы Материалы должна содержать только одно поле - Наименование. Может на момент проектирования достаточно одного поля, но в дальнейшем таблица будет разрастаться вширь, т.е. в нее будут добавлятся различные служебные поля. Также я очень не уверен, что со временем в таблицу Объекты не придется добавить служебные поля, которые будут отличаться от служебных полей таблицы Материалы. Если все сливать в одну таблицу, то в нее придется добавить все поля, относящиеся ко всем таблицам. Таким образом получите настоящую помойку, которую слили все что можно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 13:18 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Nahel ... Вопрос, правельнее будет сделать отдельную таблицу для каждого справочника или же есть более рациональный способ. Да. Для _разных_ справочников надо делать разные таблицы. В одну таблицу имеет смысл сводить только в случае, если справочники реально одинаковые. Напимер: Для таблиц ГабаритныеРазмерыТранзисторов, ГабаритныеРазмерыРезисторов и т.п. имеет смысл сделать один справочник - ГабаритныеРазмеры. И далее рулить своиствами типами и т.п. Но если в справочниках повторяется только поле название - однозначно в разные таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 13:22 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
А еще есть объектноориентированная БД Cashe. Может быть ее идеология вам подойдет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 13:28 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Видемо буду делать отдельные таблицы. Почитал про hierarchyid прикольно, но разработка идет на 2005 sql. Еще раз всме спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 13:40 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Senya_LНе все СУБД поддерживают FK, ссылающиеся на составные PK.Странно. Пример такой СУБД можно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 15:43 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Senya_L wrote: > дело. Пусть будет 40 таблиц, да хоть 100 - что тут страшного? А вот если Страшного то, что каждый из этих 40 справочников своим запросом надо обрабатывать. Вместо 4 запросов - 4 * 40 = 160 запросов. Нравится ? > множество справочников "запихнуть" в одну таблицу, то можно с ростом > объемов данных и тормоза получить при выборках типа Не получишь. > Не все СУБД поддерживают FK, ссылающиеся на составные PK. Все. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 18:50 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
MasterZiv > Не все СУБД поддерживают FK, ссылающиеся на составные PK. Все. Да, я ошибся. Я не пользуюсь составными PK, отсюда ошибка. MasterZiv> множество справочников "запихнуть" в одну таблицу, то можно с ростом > объемов данных и тормоза получить при выборках типа Не получишь.Откуда такая уверенность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2009, 21:35 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
MasterZiv Senya_L wrote: Страшного то, что каждый из этих 40 справочников своим запросом надо обрабатывать. Вместо 4 запросов - 4 * 40 = 160 запросов. Нравится ? Приведите пример, где надо объединять 40 справочников . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2009, 09:54 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Senya_L wrote: > > множество справочников "запихнуть" в одну таблицу, то можно с ростом > > объемов данных и тормоза получить при выборках типа > > Не получишь. > > Откуда такая уверенность? Из знаний, из института, из опыта, -- долго в общем объяснять. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2009, 00:03 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
дддддд wrote: > Приведите пример, где надо объединять 40 *справочников*. А я тут при чём ? Это вот авторов вопроса спрашивайте. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2009, 00:04 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
MasterZivСтрашного то, что каждый из этих 40 справочников своим запросом надо обрабатывать. Вместо 4 запросов - 4 * 40 = 160 запросов. Нравится ? Я в очередной раз прошу объяснить, в какой древней версии Акцесса или не знаю уж чего справедлив такой "страшный" аргумент. Какие ещё живы инструментальные средства, в которых не работает Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2009, 13:45 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
softwarer wrote: > Я в очередной раз прошу объяснить, в какой древней версии Акцесса или не > знаю уж чего справедлив такой "страшный" аргумент. Какие ещё живы > инструментальные средства, в которых не работает > > SQL = 'select &TableName_id, &TableName_name from &TableName' А это в любой нормальной СУБД плохо, Потому что план будет каждый раз строится, и по неизвестно какой таблице. Не, я что, я -- ничего. Нравится -- уперёд ! Смысла только нету. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2009, 14:58 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
MasterZivА это в любой нормальной СУБД плохо, Потому что план будет каждый раз строится, 1. С чего бы это вдруг? 2. Даже если вдруг где-то будет строиться каждый раз: и насколько тяжело построить план для такого запроса? MasterZivНе, я что, я -- ничего. Нравится -- уперёд ! Смысла только нету. Делать чёрт знает что из схемы БД смысла нааамного больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2009, 15:44 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
А чем плох или хорош такой вариант: На примере хранения разных видов документов: есть общая часть всех документов, таблица documents(document_ID,No,Data,doc_type_id,Note) есть таблица типов документов, doc_type (doc_type_id,name) и для каждого типа документов которому нужны доп характеристики делаем таблицы-дополнения со связью 1-1 к documents, например: prixod_apx(document_id,field1,field2...) rasxod_apx(document_id,field1...) при этом общая обработка документов (журнал, поиск, регистрация) значительно упрощается, добавление нового типа документа сразу учитывается в общих обработках, добавление характеристик в какой-либо отдельный вид документа не влияет на работу с другими видами документов, а для частных обработок документов один раз сделать вьюхи на каждый вид документа с полным набором полей для каждого вида документа и где надо - юзать их ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2009, 09:49 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
Неплохой вариант. Можно еще так: В каждой таблице документов создавать одинаковые поля для заголовка например ID NUMBER DATE DOC_TYPE ..... и потом объеденить их в одну вьюху. в этом случае при обращению к одному типу документа не надо делать никаких связок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2009, 12:52 |
|
||
|
Множество однотипных таблиц.
|
|||
|---|---|---|---|
|
#18+
LelikBolekА чем плох или хорош такой вариант: На примере хранения разных видов документов: есть общая часть всех документов, Для документов он хорош. Справочники - не документы. Разница в том, что "список документов" имеет смысл и нередко используется, а вот "список значений из всех справочников вперемешку" - бред. В том, что нам часто нужна возможность сослаться на "документ любого из множества типов", а вот ссылка на справочник всегда конкретна. В том, что разные типы документов нередко обрабатываются существенно общей бизнес-логикой, а у справочников и операций-то нет, CRUD и почти всё, и обрабатываются они поодиночке. В общем, то что хорошо для пожилого холостяка, малоудачно для матери-героини. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2009, 19:11 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36048254&tid=1543185]: |
0ms |
get settings: |
7ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
2ms |
| others: | 215ms |
| total: | 383ms |

| 0 / 0 |
