Здраствуйте, господа... Решился наконец-то разобраться с БД.
Возник такой вопросец по проектированию структуры БД.
1. Есть таблица tbl1 с полями field1-field100. Из них постоянная надобность в полях field1-field5, остальные поля нужны "когда как"/"от случая к случаю". Есть ли смысл разбить таблицу на две? Что это даст(какие плюсы, какие минусы)?
2. Есть таблица tbl2 c полями simpleField1-5 и полем достаточно громоздким(по содержимому) полем hugeBlobField. Даст ли что-нибудь выделение этого hugeBlobField в отдельную таблицу(в плане скорости)?
3. Не совсем по проектированию, но всё же: для таблицы из п.1(с сотней полей) есть ли разница в скорости для
и
когда нужны только первые три поля?

P.S. Понимаю, что вопросы глупые... потому не обижусь, если пнут в сторону какой-нибудь грамотной статьи/чтива по проектированию БД, но, желательно, чтобы это был не двух-томник войны и мира, а что-нибудь коротенькое(типа курса молодого бойца). FAQ смотрел, ссылок на чтиво не нашёл :(.
Заранее спасибо.

Вот даже как :). Т.е., если я правильно трактую Ваши слова, то при переходе с MySQL к, к примеру, Oracle(из-за увеличившейся нагрузки) придётся переделывать структуру БД, чтобы получить приемлемую производительность? Странно... мне казалось, что миграция с одной СУБД на другую - обычное дело... ну да ладно :).

Что ж... тогда посоветуйте для MySQL, заодно, посоветуте пожалуйста, какой движок лучше :).

miksoftЧто-то советовать, не зная задачи, тоже смысла мало.
Задача: спроектировать структура БД и схему работы с ней так, чтобы это было наиболее оптимально и масштабируемо для ныне популярных СУБД(MySQL, MS SQL Server, PostgreSQL, etc.) :).

Спасибо за ссылку, почитаю... Не посоветуете какого-нибудь чтива для начинающих DBA? :)

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

Программист-ЛюбительОт анализа предметной области и постановки задачи через разработку и до внедрения и сопровождения. И штоб своими собственными лапками! А чьими ж ещё лапками? :)
Собственно говоря, сейчас я и занят проектом, только мала вероятность, что проект будет куда-то внедряться(ибо делается он с одной целью - научиться) и на него будет реальная нагрузка(к примеру, такая же интенсивная как на этот форум)... А хотелось бы сделать всё "по взрослому" :), чтобы проект был расчитан на приличную нагрузку... По части программной реализации проблем не будет, а вот части БД я пока dumb...

drev , хотите сказать, что можно даже не заморачиваться с кросс-СУБД'овостью(слово то какое придумал :))?

drev , ну смотрите, есть, к примеру ADOdb(абстракция от специфики разных СУБД для PHP)... Есть аналогичные вещи для других ЯП... Смысл ими пользоваться, если всё равно придётся делать упор на конкретную СУБД? А если не делать упор, то, выходит нужно гадать на кофейной гуще... Или забыть про абстракцию уровня СУБД и делать абстракцию уровня доступа к данным, которую уже подгонять под каждую конкретную СУБД, вплоть до изменения набора таблиц, полей, связей, ХП and so on(для меня это равносильно самоубийтсву).

Goffman , дело не столько в производительности, сколько в идеалогии... Я видел несколько реально существующих и процветающих проектов, структуру их БД и организацию работы с нею... Мне не понравилось хотя бы то, что одна таблица может содержать около 50 совершенно несвязанных полей(т.е. у меня первый порыв был разбить таблицы на более маленькии, чтобы было понятно их назначение, проще было вникать в общую картину и т.д.). Или как Вам такое: в таблицы, помимо несущих смысл полей добавляются поля, значение которых по сути можно получить join'ом и некоторым условием. Зачем добавили эти поля? Очевидно для повышения быстродействия(кэширование так сказать), но почему кэш не был вынесен в отдельную таблицу мне непонятно. Хотя... даже разработчики MySQL не имеют на этот счёт общего мнения :)
7.4.2. Make Your Data as Small as PossibleIn some circumstances, it can be beneficial to split into two a table that is scanned very often. This is especially true if it is a dynamic-format table and it is possible to use a smaller static format table that can be used to find the relevant rows when scanning the table.
7.2.20. Other Optimization TipsIt is normally not useful to split a table into different tables just because the rows become large. In accessing a row, the biggest performance hit is the disk seek needed to find the first byte of the row. After finding the data, most modern disks can read the entire row fast enough for most applications. The only cases where splitting up a table makes an appreciable difference is if it is a MyISAM table using dynamic row format that you can change to a fixed row size, or if you very often need to scan the table but do not need most of the columns. See Chapter 13, Storage Engines.
С одной стороны хорошо когда данные фиксированной длины отделены от данных дин. размера(почему я изначально и спрашивал об отделении blob'ов), а с другой стороны дробить таблицу плохо, ибо самая дорогостоящая часть работы - это найти нужную строку в таблице... т.е. нужно как-то балансировать между этими двуми крайностями(стресс тесты делать или ещё как). И всё это актуально для конкретной СУБД и её конкретного движка. Печально...