| |
|
|
| | Подскажите,пож-ста,насколько необходимо ключевое поле,если логически,кроме как в виде счетчика его нет смысла ставить?у меня таблица цех,стоят поля дата,бригада,час начала,час конца,номер заказа по которой можно определить какая бригада в этом цеху в какие часы делала какой заказ.Стоит ли ставить счетчик как ключевое поле?И стоит ли делать индексированные поля?Я прочитал,что индексация полей уменьшает время поиска(как плюс) и увеличивает время добавления/редактирования записей (как минус).А как это происходит-как индексация влияет на уменьшение время поиска, т.е. если я ,например, сделаю ключевым поле дата в этой таблице,-за счет чего индексация этого поля поможет мне найти нужную дату быстрее. И только ли уменьшение времени поиска и сортировки делает целесообразной индексацию?
И еще вопрос-как можно обнулять счетчик-я экспериментирую с таблицей-постоянно удаляю записи, а счетчик ведет начало с последнего номера записи+1,несмотря на то что все записи были удалены.
Заранее спасибо. | |
| |
| |
| |
|
|
| | на счет онуления счетчика точно в нете видел статейки, поищите
а на счет счетчика как ключевое поле - совсем не обязательно
в своей базе, к примеру таблица Клиенты, у меня имет поле счетчика и назвал я его КодКлиента, в данном варианте имеет смысл делать его ключевым
а есть таблицы у меня, где вообще я не вводил даже подобное поле
если что не так сказал, не пинайте
пусть "старшие" поправят меня  | |
| |
| |
| |
|
|
| |
как можно обнулять счетчик
|
http://hiprog.com/index.php?option=com_content&task=blogcategory&id=119&Itemid=159
Q11 | |
| |
| |
| |
|
|
| | Все ниже сказанное является моим личным субъективным мнением, не претендующим на полную истинность
КЛЮЧЕВОЕ ПОЛЕ ДОЛЖНО БЫТЬ В КАЖДОЙ ТАБЛИЦЕ!!! Счетчик это или нет - вам решать.
Мои мысли о счетчиках.
1. счетчик это только ключевое поле для идентификации записи. Вские другие нагрузки типа нумерации чего-либо на него возлагать нельзя
2. Было по всякому, сейчас "1 таблица - 1 счетчик и этот счетчик ключевое поле". Даже если есть другие идентификаторы. Можно поставить уникальный ключ и использовать его в каких-то случаях, но ключ все равно счетчик, мне это кажется логичным. Если идентификатор никак не привязан к данным, то он и не может поменяться в случае изменения данных.
Простой пример, предположим мы используем номер паспорта как уникальный ключ для идентификации некоего "клиента". Вроде бы все хорошо, но вот человек потерял паспорт и получил новый.... придется изменить поля во всех таблицах где использовался ключ из таблицы клиенты.Конечно современные БД имеют встроенные механизмы поддерживающие целостность и каскадное обновление, но зачем проектировать проблему? Со счетчиком такой случай разрешается легко, просто изменением обычного поля "номер паспорта", оно может иметь уникальный ключ.
Иногда возникает соблазн сделать ключевым другое поле, ну например в таблице с полом, "там же только 2 значения", или в таблице "единицы измерения"... Теперь представим что систему вдруг стала мультиязычной... (тот ларек который ее у вас заказал, открыл филиал в Манако, но данные должны объединяться)... в этом случае счетчик опять побеждает :-)
Кому-то мои доводы покажутся не убедительными, есть довольно много плюсов в использовании в качестве ключа не счетчиков, но как говорится "О вкусах не спорят"
Вообще не считаю себя крупным спецом в индексации
С индексацией все не очень просто, много - плохо, мало - тоже плохо.
Обычно делаю индексы для полей:
- по которым будет поиск или группировка
- числовые по которым возможен поиск максимальных и минимальных
- для которых нужна уникальность
все остальные в персональных случаях когда начинаются явные тормоза. | |
| |
| |
| |
|
|
| | Из личного опыта. Рано или поздно пости во всех таблицах, в которых казалось, что ключ по счетчику не нужен, пришлось его добавлять. В простых справочных таблиц из 2х полей потом понадобились ещё поля, и ещё... А при изменениии ключей и связей потом менять кучу запросов-очень времязатратная процедура. По поводу тормоза индексах.Большое количество записей со временем становятся малоиспользуемыми. Переваливаем их в архивные таблицы, но заменяем некоторые внешние ключи на их значение-это позволит снять связи(обновления не нужны), зафиксировать эти поля по их состоянию на момент архивации(не будет каскадных обновлений) и убрать индексацию. Или даже вынести архивы в другую базу и просматривать их в простой форме без тормозных наворотов всяких проверок.
Обновление счетчика сжатием базы не удобная вещь для многоползовательской базы.
Лучше сделать один раз модуль пересоздания таблицы(или копирования по образцу), а не выбрасывать пользователей из базы. | |
| |
| |
