powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Может лучше сделать все одной таблицей?
25 сообщений из 80, страница 3 из 4
Может лучше сделать все одной таблицей?
    #38951815
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Постоянно консультируюсь с будущими пользователями... чую курсовой в диплом перетечет. Сразу столько "хотелок" я не ожидал.
Например в формируемую таблицу нужно будет добавлять поля не из каталога. Причем и нумерацию строк надо будет сделать с учетом этой строки.
А добавлять надо строки:
ОБОРУДОВАНИЕ:
ИЗДЕЛИЯ И МАТЕРИАЛЫ:
<Пользовательская строку>:
Это своего рода разделитель в общем списке
Ну и нумерация соответственно:
1 ОБОРУДОВАНИЕ:
1.1
1.2
1.3
1. ...
2 ИЗДЕЛИЯ И МАТЕРИАЛЫ:
2.1
2.2
....
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951845
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вам надо закладываться на иерархическую спецификацию, состоящую из нескольких разделов, каждый из которых в свою очередь (рекурсивно) может иметь несколько подразделов и т.д. В БД это реализуется ссылкой на себя ID - ParentID. На экране ОБЯЗАТЕЛЬНО должен быть нормальный иерархический/древовидный контрол. При щелчке по узлу должно быть отражено его содержание (с возможностью редактирования). Перемещение уровней вверх/вниз и автоматическая (пере)нумерация. В принципе не очень сложно, многое зависит от клиентского средства. Я несколько лет назад делал на мс скл сервер + аксес адп, дополненный обычным виндоузным тривью.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951889
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сейчас соберу мозги после взрыва :)
Честно говоря не понимаю зачем эта иерархическая структура. Можно поподробнее что Вы имеете ввиду и как это должно выглядеть применительно к моей базе.

Еще вопрос такой. Вот я задал размер некоторых полей 30, 50, 150 и т.д. Вот вроде бы с запасом от 20% до 200%. А вот если случится беда и как выяснится неподрасчитал и нужно потом увеличить? Как я понимаю это довольно большая проблема для клиентского приложения. Если я поля сделаю все MAX или все увеличу до больших размеров так чтобы наверняка, чем это плохо?
Понимаю, что ламерские вопросы, но все же.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951905
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы же сами только что заявили, что в спецификации должно быть несколько (более одного) раздела. При разрастании спецификации или ее усложнении очень велика вероятность, что какой-то раздел придется раздробить на подразделы. И так далее. Это - абсолютно стандартный паттерн - древовидная/иерархическая структура.

Посмотрите на проводник в режиме отображения структуры папок.

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

Таблица спецификаций должна быть разбита на две. Первая будет хранить структуру уровней спецификации. Вторая - собственно принадлежность единиц оборудования из каталога той или иной веточке структуры.

То, что вы сейчас мучительно открываете, на самом деле - стандартные, давно хорошо обкатанные паттерны проектирования. Проблема только в том, что вам они не знакомы. Поэтому я в самом начале предлагал вам сформулировать функциональные требования, как можно полнее и четче. Структура БД из них лепится без напряжения, достаточно одного спинного мозга, головной может отдыхать.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951944
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Переговорил с "заказчиком", обсудили.

В общем думаю надо добавлять еще одно поле ID_Section в таблицу Equipment_catalogue, ну и естественно добавлять таблицу Sections, где будут перечислены разделы.
Условно все оборудование в каталоге можно разделить на этих два раздела (Оборудование, Изделия и материалы). И пользователю будет очень удобно при наборе спецификации чтобы автоматом создавался (если нет) раздел и оборудование автоматом добавлялось в этот раздел. Подразделов не бывает в принципе. Но бывают скажем так "авторские разделы" с произвольным именем. Тут я думаю сделать кнопку создания раздела и пользователь потом будет перетягивать из другого раздела в этот "авторский". Или сделать птичку чтобы любое оборудование добавляемое шло в этот авторский раздел.

Что думаете насчет такого подхода?
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951989
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот так примерно получается:
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38951999
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AshoorupПереговорил с "заказчиком", обсудили.

В общем думаю надо добавлять еще одно поле ID_Section в таблицу Equipment_catalogue, ну и естественно добавлять таблицу Sections, где будут перечислены разделы.
Условно все оборудование в каталоге можно разделить на этих два раздела (Оборудование, Изделия и материалы). И пользователю будет очень удобно при наборе спецификации чтобы автоматом создавался (если нет) раздел и оборудование автоматом добавлялось в этот раздел. Подразделов не бывает в принципе. Но бывают скажем так "авторские разделы" с произвольным именем. Тут я думаю сделать кнопку создания раздела и пользователь потом будет перетягивать из другого раздела в этот "авторский". Или сделать птичку чтобы любое оборудование добавляемое шло в этот авторский раздел.

Что думаете насчет такого подхода?
Думаю, что вы не можете сформулировать требования.

авторУсловно все оборудование в каталоге можно разделить на этих два раздела (Оборудование, Изделия и материалы).
Подразделов не бывает в принципе. Каталог состоит из фиксированного числа разделов. Любая единица оборудование в каталоге относится к тому или иному, одному разделу. (в реальности фотосумка - в разделе сумок ? в разделе фототехники ?). Категорический отказ от многоуровнего каталога в будущем может аукнуться невозможностью более тонкой классификации.

авторИ пользователю будет очень удобно при наборе спецификации чтобы автоматом создавался (если нет) раздел и оборудование автоматом добавлялось в этот раздел.
Спецификация состоит из тех же разделов, что и каталог оборудования ? Пустые разделы создаются при создании спецификации ? При добавлении первого оборудования из раздела, которого еще нет в спецификации ?

авторНо бывают скажем так "авторские разделы" с произвольным именем. Тут я думаю сделать кнопку создания раздела и пользователь потом будет перетягивать из другого раздела в этот "авторский". Или сделать птичку чтобы любое оборудование добавляемое шло в этот авторский раздел.
Совершенно невнятно и непонятно. Смешано описание структуры и процедуры наполнения данными. Сумбур. Какие кнопки, какие птички...
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952038
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
П-ЛКаталог состоит из фиксированного числа разделов. Любая единица оборудование в каталоге относится к тому или иному, одному разделу. (в реальности фотосумка - в разделе сумок ? в разделе фототехники ?). Категорический отказ от многоуровнего каталога в будущем может аукнуться невозможностью более тонкой классификации.
В каталоге одна запись оборудования - один раздел. Одно и тоже оборудование не может быть в двух разделах (в каталоге).
П-Л1. Спецификация состоит из тех же разделов, что и каталог оборудования ?
2. Пустые разделы создаются при создании спецификации ?
3. При добавлении первого оборудования из раздела, которого еще нет в спецификации ?
1. Да.
2. Пустые разделы? Думаю не будет таких. Все оборудование (в каталоге) разделится четко на разделы. В спецификации будет как минимум 1 раздел всегда.
3. Создается строка с именем раздела и ниже добавляется выбранное из каталога оборудование (картинку прилагаю)

авторНо бывают скажем так "авторские разделы" ...
Совершенно невнятно и непонятно. Смешано описание структуры и процедуры наполнения данными. Сумбур. Какие кнопки, какие птички...[/quot]
Под "авторским разделом" я понимаю раздел, который создал сам пользователь в своей спецификации (не каталоге). И занес в спецификацию, из каталога, то оборудование, которое посчитал нужным, даже если оно относится к другому разделу.

Вот есть например "Светофор" - это в разделе "Оборудование". И есть "Линза светофора" - это уже "Изделие и материалы".
Крайне редко может появится еще какой раздел (для заказчика) например "Мостовое оборудование" и тот же светофор пойдет в этот раздел.

Ну вот не получается четкой классификации. Все оборудование делится... ну пусть хоть на 10 разделов. Но подразделов все равно нет и не планируется. И классификации не планируется - это все только усложнит поиск и наполнение каталога - пользы никакой.

В спецификации пользователь еще должен иметь возможность добавлять запись не из каталога. Т.е. написать руками, заполнив все поля. Проблем тут не вижу. Просто поле ID_Equipment в таблице Specification_lines будет NULL.


Наверно все, что уже можно придумать в ТЗ к программе уже все описал...
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952043
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот второй раздел.
В поле наименование пишется имя раздела - остальные поля пустые
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952063
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AshoorupПод "авторским разделом" я понимаю раздел, который создал сам пользователь в своей спецификации (не каталоге). И занес в спецификацию, из каталога, то оборудование, которое посчитал нужным, даже если оно относится к другому разделу.

Вот есть например "Светофор" - это в разделе "Оборудование". И есть "Линза светофора" - это уже "Изделие и материалы".
Крайне редко может появится еще какой раздел (для заказчика) например "Мостовое оборудование" и тот же светофор пойдет в этот раздел.

Ну вот не получается четкой классификации. Все оборудование делится... ну пусть хоть на 10 разделов. Но подразделов все равно нет и не планируется. И классификации не планируется - это все только усложнит поиск и наполнение каталога - пользы никакой.

В спецификации пользователь еще должен иметь возможность добавлять запись не из каталога. Т.е. написать руками, заполнив все поля. Проблем тут не вижу. Просто поле ID_Equipment в таблице Specification_lines будет NULL.

Наверно все, что уже можно придумать в ТЗ к программе уже все описал...
Это вам так кажется. Пока отрывочно, неполно и противоречиво описана только небольшая часть. Но даже из уже описанного видно, что схема не годится.

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

Там, где вы не видите проблемы "написать ручками" на самом деле скрыта довольно тяжелая проблема. Либо написанное ручками нужно будет добавлять в общий каталог, помечая, что это - пользовательский ввод и он должен использоваться только в одной спецификации, либо опять-таки денормализовывать спецификацию и переписывать в нее кроме айди поля из каталога. Я бы сделал по первому сценарию.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952333
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Утро вечера мудренее" (с)

Задумался над пользовательским вводом оборудования которого нет в каталоге. Думаю надо еще одна таблица User_eqipment_lines где будут храниться записи с пользовательским вводом. В таблице Specification_lines надо будет еще одно поле ID_user_eqipment_line таблицы User_eqipment_lines. Ну и получается так: если в таблице Specification_lines пустое значение в поле ID_Equipment, то читается значение из таблицы User_eqipment_lines.
Либо можно добавить поле User_eqipment в таблицу Eqipment_catalogue, помечая тем самым пользовательские записи (в поиск по каталогу они не должны попадать) - но мне кажется так сложнее потом будет организовать работу. Да и первый вариант как то не смешивает мух и котлеты.

Далее проблема с разделом в таблице Specification_lines. Думаю что нужно добавить поле ID_section и копировать значение из таблицы Eqipment_catalogue. Но значение это пользователь может менять (перетягивая в другой раздел), именно поэтому не должно быть четкой связи, а просто копирование значения.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952379
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ashoorup "Утро вечера мудренее" (с)

Задумался над пользовательским вводом оборудования которого нет в каталоге. Думаю надо еще одна таблица User_eqipment_lines где будут храниться записи с пользовательским вводом. В таблице Specification_lines надо будет еще одно поле ID_user_eqipment_line таблицы User_eqipment_lines. Ну и получается так: если в таблице Specification_lines пустое значение в поле ID_Equipment, то читается значение из таблицы User_eqipment_lines.
Либо можно добавить поле User_eqipment в таблицу Eqipment_catalogue, помечая тем самым пользовательские записи (в поиск по каталогу они не должны попадать) - но мне кажется так сложнее потом будет организовать работу. Да и первый вариант как то не смешивает мух и котлеты.

Далее проблема с разделом в таблице Specification_lines. Думаю что нужно добавить поле ID_section и копировать значение из таблицы Eqipment_catalogue. Но значение это пользователь может менять (перетягивая в другой раздел), именно поэтому не должно быть четкой связи, а просто копирование значения.
1. Делать отдельные таблицы, если данные в них похоже - настоятельно не рекомендуется. Загоняйте все в единую таблицу, помечайте признаком где пользовательский ввод, где - каталожный и в любом случае используйте айди одной (!) таблицы. Именно такой способ будет проще, а не с двумя таблицами.

2. С учетом требования наличия разделов в спецификации решение однозначное. Таблица спецификаций мастер для таблицы разделов. Таблица разделов в спецификации, в свою очередь мастер для строк спецификаций. Вопрос только иметь ли отдельные таблицы разделов для каталога и спецификаций или опять таки одну таблицу с признаком, где используется этот раздел - в каталоге и спецификации или только в спецификации (пользовательский раздел).

Ну и дальше обсасывать голую схема и доводить ее до блеска смысла нету. Надо строить прототип или сразу приложение, тогда вы на своей шкуре прочувствуете, как играет то или иное решение. Работающий, полнофункциональный прототип можно экстремально быстро слепить на адп + мс скл сервер. (по этой схеме за 2-3 дня) Он может с успехом работать пока не торопясь пишется красивый клиент на студии.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952572
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
П-Л, спасибо за рекомендации! Вот что получилось:

Еще вопрос такой: У меня в таблице Equipment_catalogue есть поле Equipment_description, которое я планирую выводить отдельно например в RichTextBox (или др.). Задача такая, чтобы запись хранила форматированный текст. Какой тип у поля должен быть?
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952588
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Забыл написать что сделал:
1. Добавил поле User_section в таблицу Sections - чтобы пометить разделы которые добавит пользователь (будет специальная кнопка для создания пользовательского раздела)
2. Добавил поле User_equipment в таблицу Equipment_catalogue - чтобы пометить записи добавляемые пользователем в спецификацию руками.
3. Добавил поле ID_section в таблицу Specification_lines - в это поле будет копироваться значение из Equipment_catalogue при добавлении оборудования в спецификацию. Пользователь неявно может менять значение этого поля.
Единственное меня смущает отсутствие связи этого поля с таблицей Sections. Если я правильно понимаю, то такая связь и называется "частичная денормализация"? Я так понимаю нужно сделать эту связь?
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952603
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MS SQL сервер не даст вам два раза связать поле ID_Section сильными связями. Если вы протянете связь от таблицы Specification_Lines до таблицы Sections то вторую связь надо делать без опции каскадного удаления или обновления. На схеме она будет пунктиром.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952650
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не понял как это сделать...
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952684
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обычным образом, как другие связи. Хватаете поле из таблицы Sections и тащите его мышкой в Specification_Lines, там бросаете. В окошке ставите галочки, какая связь.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952709
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Это я понял. Я не не понял "вторую связь надо делать без опции каскадного удаления или обновления". Это надо поменять для "Спецификация INSERT и UPDATE" поля "Правило обновления" и "Правило удаления"? А на какие значения? (при любых пунктиром ничего не меняется)
SQL Server у меня RUS
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952746
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надо снять каскадное обновление и каскадное удаление. Пишу по памяти, запустить сервер не могу. Пунктир может быть если снять контроль целостности, что-ли.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952827
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пунктир становится когда для связи выбираю "Включить использование ограничения внешнего ключа". На что это влияет не понимаю... да и разбираться уже как-то и времени нет. Если не сложно объясните для чего это делать и нужно ли.

Активно сажусь писать приложение. Курсовой сдача 04.06.2015 - времени не много. Благо на работе могу спокойно писать/учиться.
Для курсового надо показать хоть что-то. На производство программу я конечно же уже сделаю как надо.
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952847
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот картинка как сделал. А что сделал не понял :)
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952864
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Очередной учебный сферический конь в вакууме. Пишите...
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38952879
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я стараюсь :(
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38954217
Ashoorup
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Решил перенести БД на рабочий сервер.
Писал базу в SQL Server 2014 Express а перенести решил на SQL Server 2012 EE. Данные вроде все перенеслись... жаль диаграмма не копируется. Связи тоже почему-то не скопировались.
Но вот фантастика. Открываю БД которая экспортировалась на сервер через Managment Studio от 2014 и вижу что почти все как было есть кроме связей. Даже примечания скопировались. Ну связи подцепить делов на пару минут, но знать как правильно не мешало бы.
Может есть какой более правильный способ скопировать диаграмму?
...
Рейтинг: 0 / 0
Может лучше сделать все одной таблицей?
    #38954267
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переносить всю базу надо бэкапом. А бэкап нельзя поднять с более новой версии на более старой.
...
Рейтинг: 0 / 0
25 сообщений из 80, страница 3 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Может лучше сделать все одной таблицей?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]