|
| |
|
|
| |
для: tAleks
(15.06.2006 в 17:00)
| | | 100 полей не повод волноваться - если больше, следует задуматься об реорганизации базы данных (нормализации), но не из-за быстродействия, а из-за удоства использования. | |
| |
|
|
| |
|
|
| |
для: tAleks
(15.06.2006 в 17:00)
| | | Если отвечать коротко: незачем. | |
| |
|
|
| |
|
|
| |
для: Trianon
(15.06.2006 в 13:38)
| | | Вот сижу планирую органзиацию таблиц. Такой вопрос:
Если в таблице много полей, это плохо (с точки зрения быстродействия) или все равно? И не зачем об этом волоноваться....? | |
| |
|
|
| |
|
|
| |
для: tAleks
(15.06.2006 в 13:26)
| | | если у
(Клиенты - Дистрибьюторы - Подписчики (на новости и рассылки) - Партнеры)
есть общие свойства , т.е. если все они - пользователи, то будет таблица users и таблицы
clients, distributors, subscribers, partners со ссылками id_user на id в таблице users.
Если клиенту (например) необязательно быть пользователем, по id_user у него будет NULL.
qty в products - товарный запас , в lines - количество заказываемых экземпляров.
Возможно, qty в products - лишнее, если запас товара может находиться сразу в нескольких хранилищах. Тогда потребуются еще таблицы.
Все это лишь мысли, пришедшие в голову. Можно ведь и по-другому все организовать. | |
| |
|
|
| |
|
|
| |
для: Trianon
(15.06.2006 в 11:03)
| | | Поле "qty" - это, как я понимаю количество. Правильно?
И еще вопрос.
Если пользователей сайта будет несколько категорий, например:
- Клиенты
- Дистрибьюторы
- Подписчики (на новости и рассылки)
- Партнеры
Их можно в одну таблизц закинуть, например в users, и в определенном поле указать к какой категории относится, или лучше разделить их по отдельным таблицам? | |
| |
|
|
| |
|
|
| |
для: tAleks
(15.06.2006 в 10:44)
| | | напрашиваются таблицы
а) товаров: products(id, code, name, descr, price, qty)
б) покупателей: customers(id, name, address, phone)
в) заказов: orders(id, datetime, customer_id, delivery_mode)
г) позиций заказа: lines(id, order_id, product_id, qty) | |
| |
|
|
| |
|
|
| |
для: Boss
(14.06.2006 в 20:59)
| | | Но второй вариант меня смущает тем, что в каждом заказе может быть по 30 товарных позиций. И все они будут лежать в одной базе. Т.е. буедт куча одинаковых записей, только с разными ключами.
И второе. При таком варианте, когада нужно будет извлекать например информацию по какому-то заказу, нужно будет делать 2 запромса. Один запрос к таблице покуптелей. другой к таблице заказов.
Не отразиться ли это на быстродействии?
Или мои опасения по этому поводу напрасны? | |
| |
|
|
| |
|
|
| |
для: tAleks
(14.06.2006 в 14:00)
| | | Лучше сделать по 2 варианту. Так как там можно использовать внешние и первичные ключи. При этом вы будете изебегать хранение избыточной информации.
Например:
Таблица "Покупатели"
ID | name | adress
1 | Вася | .....
2 | Петя | .....
3 | Миша | .....
4 | Саша | .....
|
Таблица "Заказы"
ID | id_pok | zena
1 | 3 | 500
2 | 3 | 300
3 | 4 | 200
4 | 1 | 800
|
| |
| |
|
|
| |
|
|
| |
для: tAleks
(14.06.2006 в 14:00)
| | | Я бы предпочел второй вариант, проще осуществлять поиск и работу с заказом. | |
| |
|
|
| |
|
|
| | Как лучше всего организовать хранение заказов в Базе данных?
Каждый заказ содержит разное количество позиций.
На сегодняшний момент у меня есть 2 идеи как это организовать:
1. Все позиции, скидать в одну строку и этоу строку закинуть в одно поле в базе данных.
итого получиться что под один заказ выделяется одна строка в базе.
2. Все товарные позиции закидывать в базу, и у каждой позиции указывать в ID заказа к которому она принадлежит.
Честно сказать, не знаю что будет лучше, т.к. с PHP и MySQL знаком 3 недели. | |
| |
|
|
|
