powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше организовать?
14 сообщений из 39, страница 2 из 2
Как лучше организовать?
    #32142435
Фотография viman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Да не принято у нас никакой такой документации.
Мне тоже не нужна была документация пока не попал...
Про то как НЕ надо делать.
Узнаешь у заказчика что ему нужно (если он сам себе это представляет, что редко бывает), записываешь, исходя из объема объявляешь цену и начинаешь делать проект. НО уже ближе к концу выясняется что не хватает ОЧЕНЬ важных решений без которых от программы толку мало. Доделываешь, заказчик при этом вспоминает что ему еще потребуется и т.д.
Поэтому в момент когда ты именно записываешь все что нужно заказчику, нужно чтобы он в конце подписался хотя бы. Примитивно, но действенно (проверенно). А ТЗ оформлять очень большая работа и не под силу человеку который с этим не сталкивался.
Еще советую вставить в программу баг, который срабатывает в определенную дату. Например после такого то числа прога перестает работать (с бд вообще красота, конект с бд отрубаешь и все). Это на случай если не заплатят (грубо, но в силу Россиийской специфики необходимо), если заплатят, то программе потребуется обновление :-). Вот и все. Все здесь очень примитивно, но действенно.
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32142642
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Вот, б..., пирожок с капустой. А я был уверен, что я НЕ послал свой первый постинг. Как невыдержанный. Сорю.
Поехал отвечать.
Первым делом
wara. Ограничения на клиенте - ни в коем случае! Возможен вариант, когда на клиенте некоторые действия делаются недоступными, но это должно быть только следствием/дублированием ограничений на сервере.

Volodja
Я НЕ ВЕРЮ, что для таблицы заказов нужно 40-50 полей.
Возможный список
1. Клиент
2. Номер заказа
3. Дата заказа
4. Дата исполнения
5. Условие отгрузки
6. Условие оплаты
7. Условие страхования
8. Отметка о выполнении
9. Лицо принявшее заказ
10. Дата ввода в базу
11. Разрешение на выполнение заказа
12. Лицо, редактировшаее заказ
13. Дата редактирования
16. Предоплата
17. Получатель (если клиент забирает не сам)

Ну не получается у меня больше!

Репликант> не надо давать новичкам то, что они просят. А описание ТЗ - класное.

Volodja 2> Разумеется, для состоящего в штате фирмы программера - грамотное ТЗ - утопия. Обычно, оно заключатся в словах: "Хочу, что бы было так". Но в особо тяжелых случаях я требую завизированную формулу расчета. Что бы на меня не повесили собак за неправильно уплаченные налоги.
========
Пчелы строят прекрасные соты. Но даже самый плохой архитектор отличается от самой лучшей пчелы тем, что сначала он строит в голове.
========
Удачи, Вам, Volodja. Но базы даных - это наиболее разработанный и непонятный класс задач. С нулевого опыта никто правильную базу не построит.

Старайтесь следовать правилам нормализации.
Это... Мои правила для правильных реляционных баз. В моем вольном изложении (да простят меня Великие!)

1. Любая запись однозначно идентифицируется ключом (Кодд)
2. Значение любого поля не может быть получено на основании содержащейся в базе информации
3. Любое поле должно иметь однозначное толкование
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143019
Volodja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Cat2
К Вашему списку у меня еще добавляются:
прохождение заказа через несколько отделов и цехов, в каждый надо как минимум дату прохождения, кто провел, коментарии;
экономические параметры заказа: стоимость заказа(монтажа доставки), то же цена, пять скидок.
Итого на заказ набегает 57 полей.
Плюс данные по складированию, доставке, монтажу. Ну с этим вроде проще. Эти этапы в отдельные таблицы хорошо укладывается.
Прочитал, что SQL Server поддерживает до 1024 поля в одной таблице. Такую таблицу некрасиво делать? Или все же разбить на несколько меньших таблиц со связью один к одному?
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143074
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
От вашего списка полей убавлю ещё добрую половину. :)

Заказы
1. ID
2. Клиент
3. Номер заказа
4. Дата заказа
5. Дата исполнения
6. Отметка о выполнении
7. Предоплата
8. Получатель (если клиент забирает не сам)

Условия
1. Заказ
2. Тип (отгрузки, оплаты и т.д.)
3. Текст

прохождение заказа через несколько отделов и цехов, в каждый надо как минимум дату прохождения, кто провел, коментарии;

Подтверждения (Workflow)
1. Заказ
2. Тип (принял, утвердил, отредактировал, выполнил и т.д.)
3. Лицо
4. Дата
5. Комментарий

экономические параметры заказа: стоимость заказа(монтажа доставки), то же цена, пять скидок.

Строки Заказов
1. ID
2. Заказ
3. Предмет/товар (монтаж, доставка, материалы и т.д.)
4. Стоимость
5. Цена

Скидки
1. Заказ
2. Строка Заказа (если не указана, то скидка на заказ целиком)
3. Тип
4. Значение (% или сумма)

Итого на заказ набегает 57 полей.

Итого максимальное кол-во полей в таблице 8. :)

Нормализация!!! Порядок не помню (да и не знал никогда:)), но очень высокий, кое-что лучше бы денормализовать, например скидки, вам виднее.

Дерзайте, Volodja
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143075
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
От вашего списка полей убавлю ещё добрую половину. :)

Заказы
1. ID
2. Клиент
3. Номер заказа
4. Дата заказа
5. Дата исполнения
6. Отметка о выполнении
7. Предоплата
8. Получатель (если клиент забирает не сам)

Условия
1. Заказ
2. Тип (отгрузки, оплаты и т.д.)
3. Текст

прохождение заказа через несколько отделов и цехов, в каждый надо как минимум дату прохождения, кто провел, коментарии;

Подтверждения (Workflow)
1. Заказ
2. Тип (принял, утвердил, отредактировал, выполнил и т.д.)
3. Лицо
4. Дата
5. Комментарий

экономические параметры заказа: стоимость заказа(монтажа доставки), то же цена, пять скидок.

Строки Заказов
1. ID
2. Заказ
3. Предмет/товар (монтаж, доставка, материалы и т.д.)
4. Стоимость
5. Цена

Скидки
1. Заказ
2. Строка Заказа (если не указана, то скидка на заказ целиком)
3. Тип
4. Значение (% или сумма)

Итого на заказ набегает 57 полей.

Итого максимальное кол-во полей в таблице 8. :)

Нормализация!!! Порядок не помню (да и не знал никогда:)), но очень высокий, кое-что лучше бы денормализовать, например скидки, вам виднее.

Дерзайте, Volodja
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143076
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
От вашего списка полей убавлю ещё добрую половину. :)

Заказы
1. ID
2. Клиент
3. Номер заказа
4. Дата заказа
5. Дата исполнения
6. Отметка о выполнении
7. Предоплата
8. Получатель (если клиент забирает не сам)

Условия
1. Заказ
2. Тип (отгрузки, оплаты и т.д.)
3. Текст

прохождение заказа через несколько отделов и цехов, в каждый надо как минимум дату прохождения, кто провел, коментарии;

Подтверждения (Workflow)
1. Заказ
2. Тип (принял, утвердил, отредактировал, выполнил и т.д.)
3. Лицо
4. Дата
5. Комментарий

экономические параметры заказа: стоимость заказа(монтажа доставки), то же цена, пять скидок.

Строки Заказов
1. ID
2. Заказ
3. Предмет/товар (монтаж, доставка, материалы и т.д.)
4. Стоимость
5. Цена

Скидки
1. Заказ
2. Строка Заказа (если не указана, то скидка на заказ целиком)
3. Тип
4. Значение (% или сумма)

Итого на заказ набегает 57 полей.

Итого максимальное кол-во полей в таблице 8. :)

Нормализация!!! Порядок не помню (да и не знал никогда:)), но очень высокий, кое-что лучше бы денормализовать, например скидки, вам виднее.

Дерзайте, Volodja
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143116
Volodja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Круто.
Попробую разобраться:-)
Сразу видно, что у человека много подобных баз за плечами.
Спасибо
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143139
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сразу видно, что у человека много подобных баз за плечами.

Да нет, просто голова на плечах, а базы мы эти на завтрак кушаем по пять штук к ряду.
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143140
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сразу видно, что у человека много подобных баз за плечами.

Да нет, просто голова на плечах, а базы мы эти на завтрак кушаем по пять штук к ряду.
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143141
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сразу видно, что у человека много подобных баз за плечами.

Да нет, просто голова на плечах, а базы мы эти на завтрак кушаем по пять штук к ряду.
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143146
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что-то у akuz-а руки дрожат. Везде по 3 ответа...
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143320
Volodja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насчет Workflow.
А если в разных отделах помимо общих параметров есть еще и специфические для конкретного отдела. Как их лучше учесть: в других таблицах или эту Workflow расширить?
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143639
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Akuz очень грамотно написал один из вариантов. Но конкретный ответ может быть дан только на конкретный вопрос.

Volodja писал:
А если в разных отделах помимо общих параметров есть еще и специфические для конкретного отдела. Как их лучше учесть: в других таблицах или эту Workflow расширить?


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

2. Вложить в единые параметры свои смыслы для каждого отдела. Возможно, придется делать таблу расшифровки эти смыслов.

Допустим, для отдела "А" Парам1=0 значит "Нет возражений", а для отдела "Б" Парам1=0, значит "не могем".

Но это скользкий путь.

3. Основной метод. К каждому отделу подцеплять таблу его параметров. База будет работать при любых изменениях параметров, но запросы буду сложнее. Что не должно останавливать настоящего Профи. Но тут такая штука. Именно из за нее поектирование баз - искусство. Если сервак начнет умирать, то возможно придется использовать пункты 1 и 2.
...
Рейтинг: 0 / 0
Как лучше организовать?
    #32143657
Фотография akuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А если в разных отделах помимо общих параметров есть еще и специфические для конкретного отдела. Как их лучше учесть: в других таблицах или эту Workflow расширить?

Здесь я полностью согласен с этим утверждением Cat2:
Но конкретный ответ может быть дан только на конкретный вопрос.

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

Параметры Отделов
1. Отдел
2. Тип
3. Значение

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

Главное исходить из того, что вам же потом с этой структурой придётся работать. :)
...
Рейтинг: 0 / 0
14 сообщений из 39, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше организовать?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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