Вопрос к специалистам...
В общем, с программированием я связан давно, но с большими перерывами. Немножко программировал на Delphi, хотел перейти на С++, но прочитав на этом сайте статью .NET vs С++, где-то с полгода уже изучаю С#, правда тоже с перерывами, но все же успехи есть.
Может быть, это длинное вступление и ни к чему, но изучаю я С# это в общем, с определенной целью — написать программу — телефонный справочник. Дело в том, что имеющийся в наличии телефонный справочник г. Владивостока, содержащий около 4 миллионов телефонных номеров, поразил меня своей неэффективностью. Сейчас, получив некоторые смутные представления о реляционных БД, я понимаю, что архитектура его крайне неэффективна — все данные содержатся в одной-единственной таблице с несколькими полями: телефон, ФИО, улица, дом, квартира. Еще год назад, не зная о теории БД ничего, я придумал способ оптимизации — во первых, разделить ФИО на 3 отдельных поля, во-вторых, устранить дублирование инфрормации. Основная цель всего этого — уменьшить размер БД (около гигобайта в первоночальном варианте файла mdb), и увеличить скорость поиска до максимума по всем полям, а не только по отсортированному. Где-то с месяц назад я начал делать движок своей собственной БД, и в принципе, он показывал неплохие результаты, но из-за большой сложности программы, и отсутствия опыта проектирования объектно-ориентированных приложений, мне пришлось приостановить этот процесс и засесть за изучение "Объектно-ориентированного анализа и проектирования" Гради Буча. За месяц я переписал его несколько раз, на каждой итерации приближаясь к желаемуому результату. Потом я открыл справку по Access, начал читать ее и подумал, что все что я открыл, уже давно придумано. Кроме того, я подумал, что C# — слишком высокоуровневый язык, и может быть, есть смысл не программировать на нем все на низком уровне, а использовать уже готовые сборки для этой цели. После непродолжительного поиска в гугле я пришел к выводу — что SQLite — это то что мне надо. Но все же, поскольку теорию реляционных БД я толком не изучал, меня гложат сомнения, можно ли будет осуществить мою задумку, то есть, сделать что-то аналогичное по эффективности задуманному мной движку БД. Архитектура его такая (если вкратце): Вся бд состоит из нескольких файлов. Есть файл "объектов", есть файл "вариантов", и есть файл "свойств". Каждый объект (в данном случае это просто человек) содержит некоторое количество свойств (например, фамилию, имя, отчество, номер телефона и т.д.). Он может и не содержать некоторых свойств, конечно. Какие именно свойства он содержит, указывается в придуманном мной понятии "вариант", проще говоря, это некое подмножество универсума свойств, которые может содержать объект. "Вариант" содержит ID-ы свойств, кроме того, в файле "вариантов" все они ("варианты") отсортированы по своим ID. Хотя, все еще проще — просто порядковый номер "варианта" и является его ID-ом, поскольку варианты добавляются последовательно, ID-ы уже имеющихся вариантов не меняются. В файле объектов хранятся объекты. То есть, собственно говоря, там хранятся последовательности: {ID варианта, ID 1-го ключа, .... , ID n-го ключа}. Каждый объект также имеет свой ID. Что касается ключей, то это экземпляры свойств объекта. Например, фамилии "Иванов", "Петров", "Сидоров" свойства "Фамилия". Каждый ключ имеет свой ID, для большинства свойств достаточно 2 байта, так как, например, навряд ли существует более 65536 всевозможных фамилий, то же самое можно сказать об улицах, именах и т.д, и лишь для номеров телефонов надо 4 байта. Таким образом, достигается экономия описания объектов в файле объектов. Зная ID объекта, мы читаем его "вариант", и узнаем, какие именно "свойства" он содержит, и какова длина ID каждого свойства, далее по очереди читаем ID-ы ключей этих свойств, и извлекаем сами ключи (то есть, фамилию, имя, отчество, номер телефона, и т.д.) из соответствующих файлов. Все просто, но конечно же, необходимо еще и обеспечить поиск по ключам. Тут все немножко сложнее, но тоже в принципе, достаточно красиво. Дело в том, что в файлах ключей хранятся списки ID объектов, которые имеют данный ключ. Конечно, такие списки могут быть достаточно длинны. Например, у ключа "Светланская" свойства "Улица" будет весьма внушительный список ID объектов, потому что улица большая, и народу в ней живет много. Но фишка в том, что все эти списки будут упорядочены по ID, и для этого не надо прикладывать доп. усилий, потому как объекты по идее будут добавляться в БД последовательно, и каждый будет иметь ID на единицу больше предыдущего. Таким образом, у свойств, которыми обладает этот объект, будет добавлен ID объекта, который гарантированно больше последнего. Сами же ключи могут быть упорядочены в алфавитном порядке (правда, это немножко сложней, хотя это я реализовал), но это не принципиально, все равно, ключей не так много, и они могут быть найдены почти мгновенно, за исключением номера телефона, потому разновидностей номеров телефонов как-раз то много. После того, как мы вводим запрос например, найти всех людей с фамилией Иванов и проживающих по улице Светланской, программа находит два списка объектов, и производит их слияние, создавая результирующий список, содержащий только те ID, которые есть в обоих списках. То же самое с запросами по любому количеству свойств. После чего узнать полную информацию об объектах просто. Конечно, тут непаханное поле для оптимизаций, но не будем вдаваться в подробности.
В общем, всем кто осилил это сумбурное послание, большое спасибо. Я очень хотел бы узнать, можно ли в реляционных БД создать что-то подобное по (предположительно высокой) скорости и гибкости. Разбить большую таблицу на маленькие по полям конечно просто, но как потом искать информацию по запросам, ведь в реляционных БД нельзя создать что-то подобное описанным мной "спискам объектов". Или может я ошибаюсь?
Заранее благодарю за ответы. В довершение хочу сказать, что описанная мной архитектура придумана мной, возможно, где-то такое уже есть, если кому что известно, пожалуйста, сообщите.