Структура базы

← →
TohaNik (2002-11-23 18:08) [0]

Здравствуйте мастера.Помогите определить приемлимую структуру БД.
Попробую описать задачу.
Справочники:
1.Чертежей(3 таблицы,1-главная,2-дет к 1,3-дет к 2):
Таблица 1 (порядка 9000 записей)
PK чертеж
наим изд
калькулируемый шифр
к-т трудоемкости
марка стали

Таблица 2 (4 записи(вида заготовки)на каждый чертеж)
PK FK чертеж
PK вид заготовки

Таблица 3 (<=200 записей на каждый вид заготовки)
PK FK чертеж
PK FK вид заготовки
PK позиция
PK размер
вес заготовки
вес изделия
?- цена заготовки (стоит ли включать ее в спр-к
т.к. меняется часто)
расходный к-т металла
стружки на 1т.
обрези на 1т.
др спец. характеристики

2.Марок стали
3.Калькулируемых шифров
4.Закзчиков

Таблица плана производства:
номер заказа
заказчик
чертеж
вид заготовки
--
и т.д. данные из справочника чертежей
--
заказано шт
плановый месяц
задано в производство шт
множество вычисляемых столбцов

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

1.Реальная-ли структура спр-ка чертежей?

2.Планирую при заполнении плана грузить справочник на клиента полностью, а выбор нужного чертежа в гриде(Eh) производить посимвольным приближением к требуему. На малом, пробном, объеме
все красиво, а если справочник будет полный(грузить его могут
до пяти клинтов)как это отразится на сети?

3.Есть интуитивное желание создавать для каждого месяца новую
таблицу вроде как запросы легче строить будет хотя наверное
это неверно?

4.Необходимо будет строить сложные, ДЛЯ МЕНЯ, запросы например:

-значение некоторого поля записи еть резутатом умножения другого поля этой записи на сумму по некоторой группировке

-формула расчета некоторого поля зависит от значения первых
двух символов другого поля текущей записи

В имеющейся у меня литературе все примеры очень общие,я понимаю
что они даны чтобы их развать, но может кто-нибудь книгу посоветует с хорошим на ваш взляд описанием SQL наиболее приближенном к IB или ссылку на русском.

5.На некоторые чертежи допустима замена марки стали что влияет
только на цену заготовки. На мой взгляд это еще одна причина не включать ее в справочник или это будет както недоделано?

Спасибо если дочитали хотябы до середины.

← →
valnech (2002-11-24 11:33) [1]

> 3.Есть интуитивное желание создавать для каждого месяца
> новую
> таблицу вроде как запросы легче строить будет хотя наверное
> это неверно?

А вот этого делать не надо :)
Полностью одинаковых по структуре таблиц в БД быть не должно

← →
Desdechado (2002-11-24 16:55) [2]

1. проектирование структуры БД - это во многом искусство. Иногда правила ухудшают неформализованные решения, хотя и редко.
2. То, что меняется крайне редко, можно грузить сразу при входе в прогу. Но только в случае, когда справочники небольшие (до 1000 записей). Иначе лучше дай пользователю выбрать что-то по каким-то критериям, чтобы ограничить выборку.
4. это можно сделать в триггерах. Хотя рассчитываемые величины лучше не включать в таблицы, а вычислять при необходимости
5. если допустимы замены, значит, создай таблицу допустимых замен. Что-то типа:
материалы(код, название)
замены(код1, код2) - оба кода из таблицы материалов

← →
Sergey13 (2002-11-25 09:42) [3]

2TohaNik © (23.11.02 18:08)
>1.Реальная-ли структура спр-ка чертежей?
Обычно это называется "спецификация продукции" или что то вроде этого. Чертеж - это просто учетный документ. Поэтому не очень понятно, что ты понимаешь под словом "чертеж" - сборка или деталировка? Если сборка - то структура должна быть "деревянная" или "псевдодеревянная" (иными словами должна давать представление что куда входит), но в любом случае посложнее чем у тебя нарисовано. Если это деталировка - то опять же не видно "объединительных" данных.

>2.Планирую при заполнении плана грузить справочник на клиента полностью... а если справочник будет полный как это отразится на сети?
Ты сам себе и ответил - хреново отразится. Лучше сразу делать "правильно".

>3.Есть интуитивное желание создавать для каждого месяца новую
таблицу
Желание понятно 8-), но тут все гораздо сложнее. Как быть с заказами переходящими из месяца в месяц например? Твоя табличка подходит только для идеального примера. На самом деле тут потребуются десятки таблиц (если ты пытаешься построить реальную систему для реального производства).

>4.Необходимо будет строить сложные, ДЛЯ МЕНЯ, запросы например:
А кому щас легко? 8-(

>5.На некоторые чертежи допустима замена марки стали что влияет
Это не самый сложный вопрос - просто он лежит на поверхности.
--------------------------------
Вообще непонятно, что ты делаешь - курсовой или реальную систему? Для мастерской или завода? Если 2-2, то то что ты нарисовал - неработоспособно, ИМХО. Там все намного сложнее - сам бьюсь над этим третий год и конца края не видать. 8-(

← →
TohaNik (2002-11-25 20:00) [4]

Всем спасибо!

Для valnech © (24.11.02 11:33)

Я это, надеюсь, уже понял.

Для Desdechado © (24.11.02 16:55)

1.Постараюсь учесть.

2.Наверняка это у меня комплекс от локалок под Paradox
(интересно как всего два простых приложения могут стереотип
выработать)
Но есть один ньюанс.
Точная идентификация чертежей довольно сложна.
Например разработанный конструкторами чертеж пишется как:
номер чертежа вид заготовки позиция
2.К.11.582Р96 здесь одноз-но 02-15
ПН589.01 04

А в заявке могут написать как:

2.К11.582Р96 02,15
ПН.589-01 4

Так вот при загрузке всего справочника, используя Lookup поля
или Locate, после ввода каждого правильного символа видно окончание,а "-" вместо "." просто не введется.
Если это всетаки неприемлимо для приведенного в вопросе справочника в смысле кол-ва записей в нем,СКАЖИТЕ-ЗАБУДУ.

Первое что приходит на ум использовать в этой ситуации LIKE
на какуюто не вызывающую вопросов часть чертежа.
В возвращенном наборе(если это не одна запись) выбрать нужную
или уточнить запрос если возвращенный набор большой.
Далее еще один запрос с точным чертежом и видом заготовки и
LIKE c частичным соответствием позиции.
Или это както вкладывается в один запрос только чтобы после идентификации чертежа перебирать только подчиненный ему набор.
(Предполагаемый ответ-"пробуй",но если несложно просто схему
возможных вариантов)

4.Здесь я наверное недопонимаю.
Точнее с некоторыми расчетными величинами понятно
с др. буду думать и пока не спрашиваю.

5.Здесь ясно.

Для Sergey13 © (25.11.02 09:42)

1.Это не сборочные чертежи на изделие. У нас инструментальное
производство по заявке на конкретную деталь.Например ролик для трубных станов где позиция определяет напр. угол, а размер собственно- размер.Мы можем даже не знать где он прим-ся.

2.Понял,если можно что-нибудь по поводу выше мной написАнного.

3.Ясно.

4.Понял.

Сам толком не знаю. А вооще есть у экономистов файл(план пр-ва)в Excel
Сам туда формулы забивал.
В первый месяц(13 месяцев назад) с появлением у нас ПК (не удивляйтесь до этого была СМ-1210) этот файл имел 900 записей.
Сейчас около 3500. Т.е. каждый месяц задано шт. обнуляется;
напротив нужных чертежей ставится снова; новые чертежи довводятся
все это фильтруется и т.д. Причем у других отделов свой файл
короче можете иронизировать.
Хочу с этим что-то сделать.

Уменя просто не твой уровень. Я писал что опыта 0
IB 2 месяца назад поставил, а до этого не знал что это.
Хотя это уже нытье и не в тему.

Еще раз всем спасибо.

← →
Andrew4 (2002-11-26 01:41) [5]

приходит к Моцарту начинающий композитор и спрашивает как писать симфонии
- Вам еще рано писать симфонии - отвечает Моцарт
- Но Вы же написали первую симфонию в 9 лет - отвечает копозитор
- Да, но я не спрашивал, как писать симфонии - отвечал Моцарт

А серьезно, я такие вопросы слышу постоянно, они рождаются от двух типов людей:
1) студенты, которые на халяву хотят получить курсовик или диплом
2) Директора, которые не хотят платит НАСТОЯЩИЕ деньги за НАСТОЯЩИЙ продукт и нанимают мальчика за две копейки, который пытается что-то придумать в меру своего образования и способностей (2 коп.)
Извини, но в таком случае пишется ТЗ, рисуются бизнес-процессы, за ДЕНЬГИ нанимается профессионал, который определяет структуру таблиц, пишет программу и что там еще требуется.

← →
Sergey13 (2002-11-26 09:21) [6]

2TohaNik © (25.11.02 20:00)
Ну если твоя задача просто перевести расчет с научного калькулятора(ексель) на БД, то твоя структура может оказаться работоспособной (будут конкретные затыки - спрашивай). Но учти, что аппетит приходит во время еды. Т.е. сейчас все вводит один человек и получает свою бумажку, которая и является результатом его работы. Но в последствии он начинает задумываться, что, например, не фига ему вводить данные за которые он не отвечает. Или нафига вводить ваши чертежи, если их уже ввели в соседнем отделе? В конце концов все приходят к комплексной автоматизации. А это значит, что при вашем подходе к делу(отсутствие какой бы то ни было системы ), ты будешь переделывать свой продукт бесчисленное количество раз и он никогда не будет готов. Причем переделывать радикально. Так что Andrew4 (26.11.02 01:41) прав, излишне эмоционален (как я его понимаю!!!), но прав.

← →
TohaNik (2002-11-27 17:49) [7]

Andrew4 (26.11.02 01:41)
Sergey13 © (26.11.02 09:21)
Я только в программировании мальчик.
А вообще среда DELPHI настолько удобна,что начинающий,
связав пару-тройку таблиц впадает в некоторую эйфорию,
отсюда и вопросы в "орешник" типа:
- Я хорошо освоился в DELPHI,но еще плохо в PASCAL.
Так и у меня, током не представляя что такое IB (и вобще сервер баз данных) уже хочу
клиент-сервер.
Спасибо за участие.
Буду учиться.

← →
petr_v_a (2002-11-27 20:04) [8]

>током не представляя что такое IB (и вобще сервер баз данных) >уже хочу
>клиент-сервер

Это не страшно, люди делятся на "SQLных" и "DBFных", и я еще за свою недолгую жизнь ни разу не видел человека, который хорошо бы писал и по той и по другой технологии...

Насчет Вашей структуры - могу только порекомендовать почитать книгу Дж.К. Дейт`а "Введение в системы баз данных" и, вооружившись теорией :) оценить ее самому.
И никто Вам не сможет сказать "плохая" структура или "хорошая", ведь только Вы знаете, что это за данные ( и, соответсвенно, их структуру ) и что Вы хотите от системы

← →
MsGuns (2002-11-27 21:47) [9]

>petr_v_a © (27.11.02 20:04)
>и я еще за свою недолгую жизнь ни разу не видел человека, который хорошо бы писал и по той и по другой технологии...

Возьму на себя смелость утверждать, что я ХОРОШО (не отлично, на секундочку !) писал локальные БД (правда под ДОС - для виндузы геморроя на 2 порядка больше)

>TohaNik © (27.11.02 17:49)
>Так и у меня, током не представляя что такое IB (и вобще сервер баз данных) уже хочу
клиент-сервер.

У меня так же 8))
Так вот. Если хочешь переходить на Клиент-сервер, забудь все, что знал о КЛЮЧАХ А ПАРАДОКСЕ. Никаких "унаследованных" ключей в многоэтажных БД, а тем более использование СУЩНОСТЕЙ в качестве связующих !!!!!!

Структура базы Найти похожие ветки