 |
|
Модераторы: LSD |
 
|
|
проектирование полей БД, оптимальные решения 
| polosatij |
|
|||
 Эксперт  Профиль Группа: Завсегдатай Сообщений: 1143 Регистрация: 22.2.2004 Где: Stuttgart<-> ;Karlsruhe, Germany Репутация: нет Всего: 8 |
все, кто писал какую-либо БД задавался вопросом: сколько выделить место под например такие поля, как телефон, имя, фамилию и прочие.. может кто-нибудь кинет линком под оптимальные решения для этого? сколько, например, дать каждому полю и какой тип лучше всего для этого выбрать? (хотя с этим вроде трабл совсем нет, но всё же)  заранее пасиба!  |
|||
|
||||
Загрузка ...
| Anark1 |
|
|||
 Опытный Профиль Группа: Участник Сообщений: 622 Регистрация: 15.12.2006 Где: RF -> Moscow Репутация: 2 Всего: 11 |
Советую выделять в БД наверняка. Ну то есть , например , под полное имя - 40 символов. Человека с таким именем найти сложно, но не факт что его не существует. И так далее.
Смысл в том, чтобы данные точно влезли в таблицу, а в случае чего на клиентской части методом
можно изменить ширину отображаемого поля. -------------------- Enjoy yourself, still you can...;)   |
|||
|
||||
| polosatij |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1143 Регистрация: 22.2.2004 Где: Stuttgart<-> ;Karlsruhe, Germany Репутация: нет Всего: 8 |
Anark1,
не.. ню это понятно-то всё.. но хотелось бы увидеть best practicies |
|||
|
||||
| LSD |
|
|||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Должно гарантированно хватить. Не стесняйся выделять места побольше. Тот же varchar занимает, столько сколько в нем есть данных (ну плюс 1-2 байта) и хуже от того, что ты разрешишь забивать в него много символов - никому не будет. А вот проблемы, если ты выделишь недостаточно - будут.
-------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
| LuMee |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 117 Регистрация: 30.3.2007 Репутация: нет Всего: 1 |
Мои 5 копеек.
Необходимо еще учитывать предполагаемое количество записей в таблицах. Если оно невелико, то сильно мудрить с типами и размерами полей нет нужды: бери с запасом (мне в этом отношении нравится SQL Server'овый NVARCHAR(MAX) ).Другое дело, если у тебя счет записей идет на сотни тысяч, а то и миллионы. Тогда уже имеет смысл экономить и подбирать размеры поскромнее. Пример: есть у тебя таблица заказов, в которой есть поле, хранящее код текущего состояния заказа (в виде целого числа). Понятно, что таких состояний будет едва ли десяток, а значит использовать тип INTEGER нецелесообразно, разумнее задействовать что-нибудь помельче - TINYINT (в случае SQL Server), скажем. Аналогично, если тебе надо хранить даты рождения кого либо, то вместо DATETIME (по-прежнему на примере SQL Server) выгоднее использовать SMALLDATETIME - все равно свою дату рождения с точностью до милисекунды мало кто знает Ну и наконец, если у тебя есть строковые данные, размер которых всегда одинаков (ИНН, почтовые индексы в пределах России и т.п.), то для них лучше использовать поля фиксированного размера (CHAR(10), CHAR(6)) - вроде они быстрее пережевываются. |
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
LuMee, а есть какие-то тесты, подтверждающие твое высказывание о скорости обработки типов данных? Это не наезд, просто интересно почитать.
Со своей стороны приведу пример по InterBase: Вопрос выбора char, varchar или blob (eng) Какой тип поля выбрать - CHAR, VARCHAR или BLOB? (rus) Что быстрее - char(1), integer или smallint? (rus) -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| LuMee |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 117 Регистрация: 30.3.2007 Репутация: нет Всего: 1 |
Deniz, конкретных тестов нет, но есть кой-какой эмпирический опыт моих старших товарищей по проекту: подобным образом (уменьшение размеров полей, переход на строки фиксированного размера) оптимизировалась пухлая база на несколько десятков Гб. В результате удалось чувствительно уменьшить ее размер и повысить скорость выполнения запросов. Не в разы, конечно, но ощутимо.
|
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
LuMee, если оптимизировалась вся база, то, кроме изменения типов/размеров полей, вероятно изменялись/добавлялись индексы, процедуры и т.д., что может сыграть более значимую роль, чем varchar(100) -> char(20), ИМХО.
Я склоняюсь к тому, что для целых использовать int(big) и никаких витов или smallint и т.д. по поводу строк, вопрос неоднозначен и упирается в необходимость индексов, в любом случае я предпочту varchar вместо char -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| SergeBS |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
polosatij,
А не бывает. Кроме явно ошибочных решений типа хранения, например чисел как символьных строк. Показываю: пусть в поле нужно хранить до 100 символов. Если применять varchar(100), а не char(100) - то меньше нагрузка на дисковую подсистему и память - меньше данных надо считывать, но больше нагрузка на процессор - нужно вычислять, где фактически кончились данные. А у особо хитрых серверов, позволяющих записи переменной длины - нужно еще и вычислять, где эти данные начались. Т.е. разгружаем диск - нагружаем процессор. И наоборот. Если почитать про НФ, то там в явном виде есть оговорка: в случае необходимости уменьшения накладных расходов часто выполняемых запросов допустима денормализация. "На пальцах" - правильно, например, иметь 2 таблицы, но если все время идут запросы на выборку их объединения, то имеет смысл подумать об их объединении. Что в свою очередь вытащит проблему с непротиворечивостью данных. Насчет размеров полей - аналогично. Задашь "под обрез" - заимеешь сложности с увеличением, если это понадобится. Задашь "с запасом" - увеличишь текущую нагрузку на сервер. |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0941 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |