ну вот и напутал. конечно же связывать нужно не сущности с таблицами, а их типы с таблицами. т.е. Entity2Table это бред. читать: EntityType2Table: (entity_type:int, table:int)
, PK(entity_type, table), FK(entity_type -> EntityType.id, ), FK(table -> Table.id)
Table: (int:int, name:string)
, PK(id), FK(id -> Entity.id)
а extends из ООП extends это EntityType2Table.
В этом случае, для в ставки юзера потребуется лишь два запроса: в Entity и в User.
Есть достаточно наивный вариант, чтобы не хранить информацию о типе записи в каждой таблице.
Создадим таблицу Entity (сущности), в которой будем хранить информацию о всех идентификаторах и типах. Дополнительно создадим таблицу EntityType для хранения данных о самом типе (например, имени типа 'name'). Структуру табиц буду записывать в формате: имя_таблицы: (список полей), PK(поле первичного ключа), FK (внешний ключ)
Поле EntityType.id не генерирует значения идентификатора, а ссылается на Entity.id. Т.е. тип это тоже какая-то сущность.
Аналогично — пользователи это тоже сущности. User: (id:int, firstname:string)
, PK(id), FK(id -> Entity.id)
Пользователем, который запостил статью, может быть не любая абстрактная сущность, а лишь некто из таблицы User: Article: (id:int, user:int)
, PK(id), FK(id -> Entity.id), FK(user -> User.id)
В таблице Comment поле item ссылается на абстрактный Entity.id. Поэтому комментировать можно любые сущности: статьи, пользователей, типы,…, какие-то другие сущности, которые появятся в будущем. Аналогично для Vote.
В приципе, на одну и ту же сущность могут ссылаться id из разных таблиц. Для хранения этих данных создадим таблицу Table, где в поле name будем хранить имя табицы. А для связи таблицы таблиц с таблицей сущностей используем отношение многие-к-многим через таблицу Entity2Table: Entity2Table: (entity:int, class:int)
, PK(entity, class), FK(entity -> Entity.id, ), FK(class -> Table.id)
Table: (int:int, name:string)
, PK(id), FK(id -> Entity.id)
Таким образом для записи инфомации о новой сущности (допустим User) придется делать следующие вставки: в таблицу Entity, в таблицу User и в таблицу Entity2Table для связи вновь созданного юзера и таблицы User.
Такая структура отображается на соответствующие понятия ООП: Entity => Object, Table => Class, EntityType => DataType, Entity2Table => extends (classes).
— Огры как лук
— Воняют?
— Да нет.
— От них плачут
— Нет.
— Если их оставить на солнце то они становятся коричневыми
— Нет! У огров есть слои. И у лука есть слои. У тех и у других есть слои.
У джанго-приложений тоже есть слои, которые выражаются структурой каталога. Темпрейт-теги (templatetags/*) это расширения для языка шаблонов. В слое тегов, кодим только то, что нужно для взаимодействия с шаблонизатором. Формированием html занимаются шаблоны (templates/*) или виджеты (см. django/forms/widgets.py). А формированием контекста данных для виждетов — модели представления (admins.py, forms.py, и т.п.).
Из шаблона к блоку обращаемся через тег, из views — через функцию, а из context — по имени value в структуре данных. Т.е. блок у нас, это value внутри Context.
Декомпозиция на функции это все-таки процедурное программирование. Не в смысле плохо, просто — по-другому.
Если рассматривать данный код в разрезе MVC, то функции из view.py, обрабатывающие request, и возвращающие HttpPresponse это экстеншены для Controller. А View размазано между логикой, формирующей dictionary в таком вот обработчике запроса, и рендером шаблона внутри render_to_response('template.html', dictionary).
В качестве примера View в Django можно рассматривать django.forms.*.
Но, по большому счету, Django — не MVC фреймворк.
Посмотри Zope. Там используется подобный подход. В документации описаны случаи когда выгоднее хранить исходники в файлах, а когда в БД.
Невозможность полноценно использовать IDE
Напиши webdav интерфейс, отдающий исходники из БД, подключай этот ресурс как сетевой диск и используй любую IDE, работающую с файлами. Это сильно проще, чем писать текстовый редактор.
Use of ORDER BY for individual SELECT statements implies nothing about the order in which the rows appear in the final result because UNION by default produces an unordered set of rows
а еще лучше, вместе со своим другом, почитайте книжки по реляционной алгебре.
Чтобы получить доступ к информации на сайте нужно *купить* этот журнал.
Данная технология может продлить жизнь многим печатным изданиям, коих сейчас зажимает Интернет. А для Интернет — позволит использовать отлаженные годами способы монетизации печатных изданий.
Валидация входных данных это отдельный слой, который не относится к слою бизнес-логики. Бизнес-логика это не «логика, как обрабатывать данные», а лишь отдельная ее часть (layer) — абстрактная модель предметной области (domain logic).
Кстати про юникод. Библиотека pcre, которую используют функции preg*(), работает лишь с utf-8, и то на уровне хаков. Функции mb_ereg*(), используют движок oniguruma, где юникод поддерживается штатно. В добавок, в php эти функции прозрачно интегрируется с настройками языка (см. ru.php.net/manual/en/function.mb-regex-encoding.php).
По синтаксису регулярных выражений для mb_ereg() нужно читать www.geocities.jp/kosako3/oniguruma/doc/RE.txt, поскольку из документации из php создается впечатление, будто здесь нужно юзать тот же ублюдочный posix regexp, что был изначально в ereg(). Это не так. Oniguruma очень навороченная библиотека.
Я о другом. Если в php.ini установлен параметр mbstring.func_overload=4, то при вызове deprecated функции ereg(), будет вызываться функция mb_ereg(), которая не отмечена как deprecated. Будет-ли ворнинг?
6. это не решает проблему угона.
т.к. способом «сел и поехал» велы угоняют только наркоманы. чаще их закидывют в машину, чтобы не колесить по городу на украденном байке. следовательно, в каком состоянии у него колеса, вообще не важно. :)
EntityType2Table: (entity_type:int, table:int)
, PK(entity_type, table), FK(entity_type -> EntityType.id, ), FK(table -> Table.id)
Table: (int:int, name:string)
, PK(id), FK(id -> Entity.id)
а extends из ООП extends это EntityType2Table.
В этом случае, для в ставки юзера потребуется лишь два запроса: в Entity и в User.
Создадим таблицу Entity (сущности), в которой будем хранить информацию о всех идентификаторах и типах. Дополнительно создадим таблицу EntityType для хранения данных о самом типе (например, имени типа 'name'). Структуру табиц буду записывать в формате: имя_таблицы: (список полей), PK(поле первичного ключа), FK (внешний ключ)
Entity: (id:autoincrement, type:int) , PK(id), FK(type -> EntityType.id)
EntityType: (id:int, name:string), PK(id), FK(id -> Entity.id)
Поле EntityType.id не генерирует значения идентификатора, а ссылается на Entity.id. Т.е. тип это тоже какая-то сущность.
Аналогично — пользователи это тоже сущности.
User: (id:int, firstname:string)
, PK(id), FK(id -> Entity.id)
Пользователем, который запостил статью, может быть не любая абстрактная сущность, а лишь некто из таблицы User:
Article: (id:int, user:int)
, PK(id), FK(id -> Entity.id), FK(user -> User.id)
Продолжим:
Comment: (id:int, user:int, item:int)
, PK(id), FK(id -> Entity.id), FK(user -> User.id), FK(item -> Entity.id)
Vote: (id:int, user:int, item:int)
, PK(id), FK(id -> Entity.id), FK(user -> User.id), FK(item -> Entity.id)
В таблице Comment поле item ссылается на абстрактный Entity.id. Поэтому комментировать можно любые сущности: статьи, пользователей, типы,…, какие-то другие сущности, которые появятся в будущем. Аналогично для Vote.
В приципе, на одну и ту же сущность могут ссылаться id из разных таблиц. Для хранения этих данных создадим таблицу Table, где в поле name будем хранить имя табицы. А для связи таблицы таблиц с таблицей сущностей используем отношение многие-к-многим через таблицу Entity2Table:
Entity2Table: (entity:int, class:int)
, PK(entity, class), FK(entity -> Entity.id, ), FK(class -> Table.id)
Table: (int:int, name:string)
, PK(id), FK(id -> Entity.id)
Таким образом для записи инфомации о новой сущности (допустим User) придется делать следующие вставки: в таблицу Entity, в таблицу User и в таблицу Entity2Table для связи вновь созданного юзера и таблицы User.
Такая структура отображается на соответствующие понятия ООП: Entity => Object, Table => Class, EntityType => DataType, Entity2Table => extends (classes).
зы: сори за сумбурность. это скорее мемори дамп.
У джанго-приложений тоже есть слои, которые выражаются структурой каталога. Темпрейт-теги (templatetags/*) это расширения для языка шаблонов. В слое тегов, кодим только то, что нужно для взаимодействия с шаблонизатором. Формированием html занимаются шаблоны (templates/*) или виджеты (см. django/forms/widgets.py). А формированием контекста данных для виждетов — модели представления (admins.py, forms.py, и т.п.).
Из шаблона к блоку обращаемся через тег, из views — через функцию, а из context — по имени value в структуре данных. Т.е. блок у нас, это value внутри Context.
Если рассматривать данный код в разрезе MVC, то функции из view.py, обрабатывающие
request, и возвращающиеHttpPresponseэто экстеншены для Controller. А View размазано между логикой, формирующейdictionaryв таком вот обработчике запроса, и рендером шаблона внутриrender_to_response('template.html', dictionary).В качестве примера View в Django можно рассматривать django.forms.*.
Но, по большому счету, Django — не MVC фреймворк.
Напиши webdav интерфейс, отдающий исходники из БД, подключай этот ресурс как сетевой диск и используй любую IDE, работающую с файлами. Это сильно проще, чем писать текстовый редактор.
а еще лучше, вместе со своим другом, почитайте книжки по реляционной алгебре.
Данная технология может продлить жизнь многим печатным изданиям, коих сейчас зажимает Интернет. А для Интернет — позволит использовать отлаженные годами способы монетизации печатных изданий.
что вполне логично, для Micro$oft. :)
но я так и не увидел ответ на главный вопрос жизни, вселенной и всего такого:
:)
По синтаксису регулярных выражений для mb_ereg() нужно читать www.geocities.jp/kosako3/oniguruma/doc/RE.txt, поскольку из документации из php создается впечатление, будто здесь нужно юзать тот же ублюдочный posix regexp, что был изначально в ereg(). Это не так. Oniguruma очень навороченная библиотека.
т.к. способом «сел и поехал» велы угоняют только наркоманы. чаще их закидывют в машину, чтобы не колесить по городу на украденном байке. следовательно, в каком состоянии у него колеса, вообще не важно. :)