|
|
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Сейчас в mdb с данными есть неколько (14) небольших таблиц (до 100 записей) с 2 полями: Id Name Из названий таблиц вижу что в них хранится. Удобно, в принципе. Но вот пришла в голову мысль: а что если все эти списки затолкнуть в одну таблицу, в которую добавить третье поле, вроде: List_id по которому потом вытаскивать нужный список. Станет немного ненаглядно. И в запросе, где, например, раньше фигурировали 3 разных таблицы со списками, теперь новая таблица будет присутствовать 3 раза. Вопрос. Стоит ли с этим заморачиваться? Есть ли какие преимущества второго варианта перед первым? База сетевая. С этим mdb работает 15-20 компов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:26:46 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
автор Вопрос. Стоит ли с этим заморачиваться? Есть ли какие преимущества второго варианта перед первым? приемущество в том, что добавление нового списка не влечет за собой добавление новой таблицы, да и обращение ко всем спискам можно реализовать одним запросом, передавая ему в качестве параметра List_id, ну и ещё какие-нить бонусы. а минусов особых нет IMHO объединяй в одну таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:31:48 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Минусы появятся, как только эти справочники начнут обрастать дополнительными характеристиками. На предыдущем месте работы я как раз разграбал такое безобразие, когда два десятка справочников в одну таблицу были слиты. Плюсов, кстати, такое решение и не имеет на самом деле. Все равно ведь будет лениво каждый раз писать "Select ID, Name Form Справочники Where ListID=XXX"? Поэтому очень скоро начнется сохранение таких запросов в базе. И получается - что лишнюю таблицу сделать, что лишний запрос написать. З.Ы. Еще минус объединения. Про ссылочную целостность можно забыть. З.З.Ы. Да и вообще, разные сущности нефиг хранить в одном месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:39:13 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
автор Все равно ведь будет лениво каждый раз писать "Select ID, Name Form Справочники Where ListID=XXX"? Поэтому очень скоро начнется сохранение таких запросов в базе. можно и один запрос типа Select ID, Name Form Справочники Where ListID=[parListID] :) согласен с тем, что это вопрос спорный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:41:57 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Меня примерно такие же мысли посетили. Спасибо. Но вот остается еще вопрос: Что дает меньшую нагрузку на сеть в примере запроса, который привел выше, первый или второй вариант? Или несмотря на то, что во втором варианте, новая таблица фигурирует в запросе 3 раза, данные из нее будут скачаны за 1 раз? Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:44:31 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
я так думаю, что меньшую нагрузку на сеть даст первый вариант а по поводу сколько раз Access будет обращатся к таблице во втором варианте - это одному оптимизатору запросов известно, хотя может ЛП и знает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:47:42 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Вообще-то при цифрах "14 таблиц, до 100 записей" о количестве обращений можно не думать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:50:00 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
2 Лох Позорный Это понятно. Вопрос в принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:52:30 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Есть общепринятое правило построения реляционных баз данных: одна сущность - одна таблица. Как у всякого закона, у него есть исключения, но принцип должен быть один: если можешь не нарушать - не нарушай. По опыту - только так кажется, что если создать универсальный справочник, всунув туда еще одну колонку, то легче будет. На самом деле любая база развивается, и однажды эта фишка начнет сильно мешать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 17:55:22 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
У меня есть небольшой опыт по созданию универсального справочника. Только вместо добавления поля я добавил таблицу, обеспечивающие описание групп и связи между ними (Типа GroupID, CodeId), это дает больший универсализм. Сейчас в справочнике полторы тысячи групп. Как представлю, что это могло быть полторы тысячи таблиц, жуть берет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2004, 11:13:06 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
если справочники однотипные, то да, а если справочники значительно отличаются, то разные таблицы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2004, 11:24:03 |
|
||
|
Как оптимальнее хранить небольшие списки в базе?
|
|||
|---|---|---|---|
|
#18+
Я пользуюсь 2-мя связанными таблицами Грубо говоря одана - вид справочников (22 записи) вторая сами справочники (300 записей). Имхо это удобнее чем 22 таблицы. А еще мне нравится открывать таблицу "вид справочников", выбирать нужный справочник и открывать его в виде подчиненной таблицы. Разумеется, это второстепенные справочники, для которых не требуется обеспечение целостности ибо ввод через поле со списком отлично обеспечивает его. (Кстати, если есть уверенность, что ваш интерфес при вводе данных не позволяет нарушить целостность её можно отключить, чтобы ускорить ввод данных). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2004, 16:36:50 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32761604&tid=1670585]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 468ms |

| 0 / 0 |
