Привет!
Я вот тут задумал сделать маленькую энциклопедию, которую потом, может быть сделаю частью сайта. Естественно это БД, однозначно. Только вопрос возник в следующем. Как вы считаете, логичнее будет сделать 29 однотипных таблиц на каждую возможно-используемую букву или же одну таблицу с выделенным столбцом под букву?
Если смотреть первый вариант, то типовая таблица такая:
например: T_A (таблица буквы А)
id | NazvanieS | Text
Соответственно запрос.
Если смотреть таблицу второго варианта получается так:
id | Bukva | NazvanieS | Text
Соответственно страница строится из запроса.
Конечно, еще логичнее использовать какой-нить движок, типа Вики, но интереснее самому =)))
Всем огромное спасибо!!!
24 октября 2009 в 18:03
конечно имеет. места занимает не очень много, а скорость увеличивает значительно.
24 октября 2009 в 11:02
Простите за дотошность, но имеет ли смысл такая сложная система в веб-приложении? Я с трудом могу предположить, что в рамках идеи, о которой я говорил в самом начале, вся база будет иметь более 20000 записей в самом отдаленном будущем.
24 октября 2009 в 9:01
Александр, это достаточно сложная концепция чтобы не имело смысла объяснять ее в комментариях.
//en.wikipedia.org/wiki/Index_(database)
24 октября 2009 в 8:02
Но ведь, получается, индекс будет эффективен тогда, когда база потенциально имеет объем как у Википедии. Или нет? И можно пример индекса? Если не трудно.
24 октября 2009 в 7:05
обычно индекс – это упорядоченное дерево, узлы которого указывают, где искать соответствующую узлу запись таблицы. как правило, индекс дублирует данные полей, в него входящих, увеличивая тем самым объем базы данных.
24 октября 2009 в 7:04
А можно поподробнее с этого места? "но в каталогах объектов базы данных вы не увидите его среди таблиц " – как это так?
И как, например, индексы выглядят в принципе? К сожалению мой опыт работы с СУБД достаточно мал и индексами там я не пользовался – массив данных слишком мал.
23 октября 2009 в 23:01
Ну почему же, в определенном смысле таблица
Если не кластерный.
23 октября 2009 в 23:01
>> Ну почему же, в определенном смысле таблица
нет, конечно, в каком-то смысле это, безусловно, таблица, и место занимает
но в каталогах объектов базы данных вы не увидите его среди таблиц (не буду заявлять, что применимо ко всем базам данных, но ко многим – это точно).
23 октября 2009 в 22:05
индекс – это не таблица.
23 октября 2009 в 21:00
А это не создаст излишнюю таблицу, которую можно было избежать?
23 октября 2009 в 10:02
Ну да, если только названия извлекать, то так даже быстрее будет.
23 октября 2009 в 7:03
Леонид maxleo Максимов
>> Даже при наличии кучи статей нашел одну-рядом в памяти все остальные и выдал юзеру список
просто включите название в индекс с полями (название, идентификатор). делов-то.
T_Enc
id | Identitficator | NazvanieS | Text
T_Identif
id | Identitficator | id_t_enc
Примерно так?
22 октября 2009 в 22:05
>> Даже при наличии кучи статей нашел одну-рядом в памяти все остальные и выдал юзеру список
просто включите название в индекс с полями (название, идентификатор). делов-то.
22 октября 2009 в 10:00
Чтоб искать было быстро. Даже при наличии кучи статей нашел одну-рядом в памяти все остальные и выдал юзеру список.Дальше нюансы как субд работает, можно еще и обычный индекс прикрутить. Понятно не смогу объяснить, рисовать надо.
В асп.нет
Server.HTMLEncode(string)
Также есть встроенные механизмы защиты от различного зловредного ввода, не только от сценариев (можно отлючить в machine,webconfig и директиве Page). Но не рекомендуется.
Называется параметр ValidateRequest=true\false
22 октября 2009 в 8:02
>Как можно сделать проверку того, что в текст в БД нельзя внести какой-нить зловредный скрипт(javasсript…)?
в PHP это htmlspecialchar() или гугли
22 октября 2009 в 7:00
>А чем отличается кластеризованный индекс от обычного?
>Как можно сделать проверку того, что в текст в БД нельзя внести какой-нить зловредный скрипт(javasсript…)?
21 октября 2009 в 23:04
>> чем товарищам не нравится кластеризованный индекс по названию темы?
а зачем там кластерный индекс? достаточно обычного.
21 октября 2009 в 20:04
Антон и Александр, это бред, для чего по вашему придуманы индексы? Там что, триллионы записей предлагается хранить? Дык тогда РБД в принципе лесом идут.
Не надо извращатся, сделайте просто и чтобы работало. Вколотить костыль всегда успеете.
21 октября 2009 в 18:04
Кхм… кхм… а чем товарищам не нравится кластеризованный индекс по названию темы? По моему это очевидно.
21 октября 2009 в 18:03
Николай DuddIds Терентьев
Может я что-то не понял, но зачем тебе в таблице атрибут Bukva? Можно же без него обойтись. Когда будешь искать, то просто ищешь типа like $var."%". Я так думаю вот.
по поводу этого атрибута я писал выше. =)
Думаю, что эффект от такого атрибута будет когда таблица перерастет несколько десятков тысяч записей(проще из нее выбрать все поля таблицы, где атрибут Bukva одинаковый, чем просеять таблицу до конца ища "а где это такая буква первой завалялась?!" ), с одной стороны, и с другой стороны, проще графически отобразить. Например: нужна главная страница с алфавитом: соответственно запрос собирает все поля из атрибута Bukva, сравнивает есть ли одинаковые и выстраивает список букв. (Хотя может и проще сделать просто html-код со ссылками, но так в идеале, все ж с БД) потом при переходе на выбранную страницу новый запрос формирует данные, подставляемые в эту страницу. Я так это представляю.
> А mysql не поддерживает секционирование по диапазонам?
Скажите, а насколько велик эффект от секционирования в БД для web-приложения?
21 октября 2009 в 17:00
Может я что-то не понял, но зачем тебе в таблице атрибут Bukva? Можно же без него обойтись. Когда будешь искать, то просто ищешь типа like $var."%". Я так думаю вот.
21 октября 2009 в 17:00
хм. значит 1с мне совсем мозг вынес
> А mysql не поддерживает секционирование по диапазонам?
на оракле сидел
понятия не имею
21 октября 2009 в 16:03
> а) потому что where A=B вычисляется быстрее, чем where A like B
С какой стати?
> б) потому что в будущем легко сделать секционирование по полю Bukva
А mysql не поддерживает секционирование по диапазонам?
> Может там несколько килобайт
Названия не бывают несколько килобайт.
> базе данных понадобится перелопатить огромные массивы байт
Это невозможно.
21 октября 2009 в 15:05
человек же хочет гиговую БД сделать
вот я и предположил (см. #1) что доп. колонка Bukva будет хранить одну букву (размер char(1)) – первую букву от слова (или фразы)
соответственно небольшой перерасход места (1 char в строке) компенсируется увеличенной скоростью работы:
а) потому что where A=B вычисляется быстрее, чем where A like B
б) потому что в будущем легко сделать секционирование по полю Bukva
PS я же не знаю размер поля NazvanieS. Может там несколько килобайт. Чтобы сделать where … like базе данных понадобится перелопатить огромные массивы байт, а если сделать лишнюю колонку Bukva где хранится одна буква, то оптимизация налицо (хоть и не совсем по правилам)
21 октября 2009 в 15:01
Ээээээээээээээ, Антон.
Кагбэ
select * from T where NazvanieS like 'A%'
21 октября 2009 в 13:05
берем твою таблицу id | Bukva | NazvanieS | Text
делаем:
select * from T where Bukva='A' order by Text
здесь 'A' – это параметр, переданный в функцию запроса (см. пост выше)
21 октября 2009 в 13:04
Функции в смысле в PHP. Чтобы запрос строила функция, а выводила другая. Это позволит менять запросы без переписывания большого кода (и без долгих поисков в коде).
Секционирование – это логическое (или физическое) разделение таблицы на куски средствами самой БД по определенному правилу. Например можно делить документы в 1С по годам или месяцам (из пальца пример).
При этом с точки зрения запроса таблица одна.
21 октября 2009 в 13:03
Антон RichDad Кононов
только не забывай все в функции кидать, чтобы в будущем эту оптимизацию все-таки сделать
В смысле функции в SQL коде или в веб?(asp, php)
Я где-то проморгал. А что такое секционирование в БД?
Александр Микинас
А зачем тебе еще отдельный столбец с буквой, если уже есть название ?
Проще формировать страницу, где нужно последовательно вывести все, что там имеется, автоматически делая упорядочивание по алфавиту.
Или база плохо работает с индексами по текстовым полям ?
Предполагается что запрос вида: select from T_Enc where NazvanieS like %A% ?
И таким образом упростив структуру написать соответствующие 29 скриптов? Или внести в код страницы временную переменную, которая будет забирать значение из name нажатой ссылки и вставлять в один единственный скрипт?
21 октября 2009 в 13:00
логика тебе, думаю, не изменяет
ты же сам понимаешь, что 29 таблиц не упростят, а усложнят твою работу как программиста
на данном (начальном) этапе разработки, тебе можно вообще не заморачиваться на оптимизацию по скорости
только не забывай все в функции кидать, чтобы в будущем эту оптимизацию все-таки сделать
21 октября 2009 в 12:05
Зачем, по-твоему, нужно 29 однотипных таблиц? Ты знаком с оператором "select..where"?
21 октября 2009 в 12:05
Вопрос вот в чём: А зачем тебе еще отдельный столбец с буквой, если уже есть название ? Или база плохо работает синдексами по текстовым полям ?
Если база поддерживает секционирование таблиц, можно валить в одну таблицу.
21 октября 2009 в 12:05
Александр Volunteer Асланьян, ты не поверишь, но делай все в одной таблице.
Думается мне, что не скоро еще твоя "энциклопедия" дорастет до необходимости секционирования)))