|
|
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
Ну и наконец схема БД. Там только таблицы которые относятся к процессам которые я описал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2009, 13:05 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
Oleg Kondratskiy, Свои пять копеек по поводу не структуры, а именования: 1. Непоследовательны наименования ключей, то ID_<ENTITY>, то <ENTITY>_ID. Нужно что-то одно. Лично мне нравится <ENTITY>_ID: RESOURCE_ID, DEMAND_ID итп 2. Я бы убрал нафиг TBL_. Таблицы можно и без префиксов создавать. 3. Если есть семантически отличия между ключами ID_TREE в различных таблицах (т.е. это принципиально различные сущности), то и назвал бы их по-разному. Например, в таблице TBL_GRAPH_BRIGADE_TREE - GBT_ID (GB_TREE_ID итп), а в таблице TBL_BRIGADE_WORKER_TREE - BWT_ID (BW_TREE_ID итп). Потом легче будет просматривать свои запросы. 4. Наименования некоторых таблиц в единственном числе, некоторых во множественном. Опять таки лучше выбрать что-то одно. 5. Наименования полей, являющихся внешними ключами, сделал бы идентичными с именем поля первичного ключа таблицы, например: TBL_USERS: USER_POST_ID и в таблице TBL_USERS_POSTS поле ключа - USER_POST_ID. Не надо будет ломать голову и лазить каждый раз к диаграмме, чтобы вспомнить как то или иное поле называется: select ... from users as u join user_posts as up on up.user_post_id = u.user_post_id Ну это так - мелкие придирки. Зачастую спорные - и без всего это будет работать :) А чтобы понять структуру нужно хорошенько въезжать в процесс. Времени мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2009, 14:15 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
dymkaOleg Kondratskiy, Свои пять копеек по поводу не структуры, а именования: 1. Непоследовательны наименования ключей, то ID_<ENTITY>, то <ENTITY>_ID. Нужно что-то одно. Лично мне нравится <ENTITY>_ID: RESOURCE_ID, DEMAND_ID итп 2. Я бы убрал нафиг TBL_. Таблицы можно и без префиксов создавать. 3. Если есть семантически отличия между ключами ID_TREE в различных таблицах (т.е. это принципиально различные сущности), то и назвал бы их по-разному. Например, в таблице TBL_GRAPH_BRIGADE_TREE - GBT_ID (GB_TREE_ID итп), а в таблице TBL_BRIGADE_WORKER_TREE - BWT_ID (BW_TREE_ID итп). Потом легче будет просматривать свои запросы. 4. Наименования некоторых таблиц в единственном числе, некоторых во множественном. Опять таки лучше выбрать что-то одно. 5. Наименования полей, являющихся внешними ключами, сделал бы идентичными с именем поля первичного ключа таблицы, например: TBL_USERS: USER_POST_ID и в таблице TBL_USERS_POSTS поле ключа - USER_POST_ID. Не надо будет ломать голову и лазить каждый раз к диаграмме, чтобы вспомнить как то или иное поле называется: select ... from users as u join user_posts as up on up.user_post_id = u.user_post_id Ну это так - мелкие придирки. Зачастую спорные - и без всего это будет работать :) А чтобы понять структуру нужно хорошенько въезжать в процесс. Времени мало. 1. У меня ID_<ENTITY> для primary key а <ENTITY>_ID для FK =) Как то успел уже к этому привыкнуть =) 3. Хорошие сокращения ))) Как я сразу до них не додумался ? =( 5. Вроде как относится к 1 ответу ))) спс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2009, 14:33 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
>> Составил схему бизнес-процессов =) ну а точнее что то приближённое =) Вообще-то, я говорил про словесное описание... Повторюсь, опишите, что именно должно храниться и как обрабатываться. Ваши схемы описывают движение, а нужно описать особенности хранения с учетом движения. P.S. А прикладывать рисунки, аналогчиные "Материалы.jpg" по качеству вообще считаю издевательством. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2009, 11:28 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
Kirill Razuvaev >> Составил схему бизнес-процессов =) ну а точнее что то приближённое =) Вообще-то, я говорил про словесное описание... Повторюсь, опишите, что именно должно храниться и как обрабатываться. Ваши схемы описывают движение, а нужно описать особенности хранения с учетом движения. P.S. А прикладывать рисунки, аналогчиные "Материалы.jpg" по качеству вообще считаю издевательством. Сори но файлы свыше 100kb не прикрепить =( Обработал как смог =( Описание части учёта материалов . Есть справочник материалов (tbl_resources) который содержит: название материала, группу материалов, единицу измерения и стоимость. Сущность материалы - единица измерения материалов . Каждый материал должен иметь единицу измерения, которая берётся из справочника единицы измерения(tbl_resources_ei). Аналогично устроена сущность тип материала берётся из таблицы типы материалов(tbl_resources type). Планируется что в справочнике материалов будут храниться и обновляться практически все существующие материалы. Этот список хочу выкачивать с диска прилагаемого к журналу "Сметные цены в строительстве". Цены обновляются каждый месяц и в связи с этим необходимо и обновлять таблицу. Есть склад(tbl_sklad) в этой таблице будут храниться материалы имеющие в наличии и их количество на базе. Сущность склад-ресурсы : На складе могут храниться материалы только из справочника. Пользователь при закупке материалов будет выбирать материал из списка и вводить кол-во которое он купил. Хочу сделать ещё одну таблицу для хранения затрат на эти ресурсы. тоесть сделать ещё одну сущность склад - затраты, один ко многим. при вводе данных по закупке пользователей будет ещё вводить сумму за купленный материал. Таблица заявки(tbl_demand). В этой таблице будут храниться заявки с объектов на материалы. Каждая заявке имеет свой номер(number(integer)) и может содержать один или несколько материалов.// Может имеет смысл номер заявки хранить не в integer а в varchar и стоставлять номер примерно так: код объекта_дата_кол-во материалов в заявке. пример 3_17/07/2009_8 и сделать поле UNIQUE. ? Есть таблица перемещений(tbl_moving) которая служит для хранения данных перемещений материалов. Сущность передвижение - заявка служит для привязке премещений к заявкам. тоесть перемещать материал со склада можно только по заявке. Сущность заявка-материалы служит для определения какой материал перемещается. Я уже понял что сущность передвижение - объект лишняя, т.к. для определения объекта на который отправляется материал можно определить по сущности заявка- объект. Ну как то так. Посмотреть бы как нормальное описание выглядет . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2009, 14:36 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
Oleg Kondratskiy Описание части учёта материалов . Есть справочник материалов (tbl_resources) который содержит: название материала, группу материалов, единицу измерения и стоимость. Стоимость не должна быть привязана к матералу. Она может меняться. Себестоимость может расчитываться с учетом партионности закупок и продаж по фифо, лифо, среднему. Стоимость продажи - цена в прайс листе, зависящая от кучи факторов. Сущность материалы - единица измерения материалов . Каждый материал должен иметь единицу измерения, которая берётся из справочника единицы измерения(tbl_resources_ei). Аналогично устроена сущность тип материала берётся из таблицы типы материалов(tbl_resources type). Материалы могут поступать на склад и отпускаться со склада разными единицами. Приняли коробку, продали штуки и т.п. Планируется что в справочнике материалов будут храниться и обновляться практически все существующие материалы. Этот список хочу выкачивать с диска прилагаемого к журналу "Сметные цены в строительстве". Цены обновляются каждый месяц и в связи с этим необходимо и обновлять таблицу. Есть склад(tbl_sklad) в этой таблице будут храниться материалы имеющие в наличии и их количество на базе. Сущность склад-ресурсы : На складе могут храниться материалы только из справочника. Пользователь при закупке материалов будет выбирать материал из списка и вводить кол-во которое он купил. Хочу сделать ещё одну таблицу для хранения затрат на эти ресурсы. тоесть сделать ещё одну сущность склад - затраты, один ко многим. при вводе данных по закупке пользователей будет ещё вводить сумму за купленный материал. Таблица заявки(tbl_demand). В этой таблице будут храниться заявки с объектов на материалы. Каждая заявке имеет свой номер(number(integer)) и может содержать один или несколько материалов.// Может имеет смысл номер заявки хранить не в integer а в varchar и стоставлять номер примерно так: код объекта_дата_кол-во материалов в заявке. пример 3_17/07/2009_8 и сделать поле UNIQUE. ? Есть таблица перемещений(tbl_moving) которая служит для хранения данных перемещений материалов. Сущность передвижение - заявка служит для привязке премещений к заявкам. тоесть перемещать материал со склада можно только по заявке. Сущность заявка-материалы служит для определения какой материал перемещается. Я уже понял что сущность передвижение - объект лишняя, т.к. для определения объекта на который отправляется материал можно определить по сущности заявка- объект. Обычно как раз по основной таблице движений (принято-отпущено) остатки получаются как функция времени Ну как то так. Посмотреть бы как нормальное описание выглядет . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2009, 14:51 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
авторTBL_BRIGADE - Таблица бригад рабочих TBL_BRIGADE_WORKERS_TREE - Дерево привязки рабочих к бригадам TBL_COUSTS - таблица затрат TBL_GRAPH - Основная таблица. Хранятся задачи и их сроки.еще раз про названия таблиц. оказывается есть любители TBL и за бугром.. Вот что пишет про таких Джо Селко "Особенно глупо выглядит приставка TBL ... что еще это может быть? Вы же не ставите приставку СУЩ перед каждым написанным Вами существительным" стр. 10 книга "Стиль программирования Джо Селко на SQL" ISBN 5-469-01396-0 издательство "Питер" СУЩ_Ложка, СУЩ_Вилка, СУЩ_Колбаса (эта строка моя но по Вашим правилам) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2009, 11:15 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
Лучше бы разделить : табличную (реляционную) структуру - от информационной : http://flexiobjdb.narod.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2009, 22:33 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
> http://flexiobjdb.narod.ru/ Забавный велосипед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2009, 23:30 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
По поводу префиксов 'TBL_' я не согласен - нужны они: 1. Ежу конечно понятно, что это таблицы, хотя есть же еще и виды !!! префикс V_ или View_ Откройте Excel и посмотрите как удобно видеть, если есть префиксы 2. Ну и самое главное, что они группируют таблицы вместе, чтобы не тусовать с системными или другими таблицами. Когда-то в Оракле можно было иметь только одну базу и таблицы под разные задачи группировались именно префиксами, - с одной базой могут работать совершенно разные приложения ну а мнение авторов многих книг особенно субъективно в плане любого именования. Одним нравится одно, другим другое. Нужно видеть конкретную выгоду от именования в работе с конкретным инстументом. Вообще автор этого топика не так уж и неопытен, имена ДЛИННЫЕ мне нравтся - все понятно - сокращение - враг понимания, есть же и альясы в запросах!!! Структура тоже ничаво так, да и применение блок-схем вполне современно и классно. Нормуль короче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2009, 14:17 |
|
||
|
Покритикуйте структуру БД
|
|||
|---|---|---|---|
|
#18+
MSSQL_USERПо поводу префиксов 'TBL_' я не согласен - нужны они: 1. Ежу конечно понятно, что это таблицы, хотя есть же еще и виды !!! префикс V_ или View_ и в чём их принципиальное отличие с точки зрения клиентских приложений, интересно? Как раз такие префиксы раскрывают особенности реализации, которые стоит скрыть от потребителей данных, имхо MSSQL_USERОткройте Excel и посмотрите как удобно видеть, если есть префиксыкуда куда посмотреть, простите? MSSQL_USER2. Ну и самое главное, что они группируют таблицы вместе, чтобы не тусовать с системными или другими таблицами. имхо, для этого стоит применять совсем другие префиксы, несущие смысловую нагрузку. Просто группировка таблиц вместе мало интересна на самом деле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2009, 14:49 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36095760&tid=1543084]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
143ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 438ms |

| 0 / 0 |
