|
Разработка notes-приложений / Отслеживание удаления документов из базы
| 05/18/2011 04:03:43 PM |
|
экст манагер это конечно круто, но есть недостатки.
мы делаем свое софт-удаление. т.е. помечать документы на удаление разрешаем кому надо по бизнесу, а вот хард удаление делает только админ\выделенный чел.
выгоды:
1. пользователь не видит меченные доки и думает что они удалены
2. можно удалять(метить) все связанные логикой док-ты (тут еще можно добавить уникальный код единный для всей группы отмеченных документов, типа сессия удаления)
3. легко восстановить, когда пользователь несет жидкие конфеты.
|
Разработка notes-приложений / "Поля" в ViewSelection
| 02/03/2011 10:16:52 AM |
|
сайд эффект: в какой-то момент в документах появляются поля упомянутые в View Selection через FIELD fname:=... т.е даже догадываюсь когда, когда документ редакт\сохранен на UI из этой вьюшки. Факт появления полей зафиксирован, а дальнейшие исследования делать было некогда.
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 10/17/2010 05:16:37 PM |
|
да, у нас таких объемов нет, может тогда и решение было бы иным. вьюшка выполняет роль интерфейса, чтоб без надобности снаружи в документы никто не лазил
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 10/07/2010 04:51:47 PM |
|
| Цитата: | Сообщение от Ник Норкин | Мить,
ещё одно исключение из твоей теоремы
Я в последнее время активно использую DbColumn из специализированных вьюшек
(Forms), (Views), (Agents) и т.п. |
|
а чуть подробней, может мне тоже надо
|
Обо всем / JavaScript patterns, Stoyan Stefanov,2010 sep/ полезная книжка, однако
| 09/30/2010 09:16:56 AM |
|
<a target="_blank" href="http://depositfiles.com/ru/files/fx4b0gnuu">JavaScript patterns, Stoyan Stefanov,2010 sep</a>
ToModerator:
1. я тупой, у меня не получается вставить ссылку нормально
2. не смог отредактировать тему, удалите пож-ста название книги из темы, будем сюда ссылки кидать на полезности книжные, если никто не против
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 09/20/2010 08:40:49 PM |
|
не, я же сразу сказал, что это провокация. понятно, "ничто не слишком" © Кармадон
что касается производительности, то большие вьюшки, это понятие сложное. Большое число сорт. столбцов, большой объем выводимой информации - да, а большое кол-во ключей в одном столбце...
ну вот живой пример: 50тыс. документов, в лукапной вьюшке от 3-15 ключей в зависимости от типа док-та - летает.
Не исключаю, что если есть 1 млн. документов одного типа и 2-3 тыс. доков других типов, то лучше их разделить, но для очень больших массивов, по-любому спец. оптимизация.
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 09/20/2010 04:18:16 PM |
|
| Цитата: | Сообщение от Ник Норкин | ах, да...
надеюсь, ты не мухлюешь,
и не используешь интерфейсные представления для лукапа
(извини, это не очевидно из формулировки теоремы) |
|
да у нас за это "канделябром", хотя кое-где встречаются в аннальном коде (код из анналов истории) - давим, когда руки доходят.
в остальном ты совершенно прав, в лукапной вьюшке всего два столбца:
1. Ключевой:многозначный,все ключи имеют имя-префикс
2. Контейнер с "значимыми" значениями полей ))
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 09/20/2010 10:37:18 AM |
|
согласен, если требуется и юник и datetimerange , тогда три ))
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 09/19/2010 01:45:43 AM |
|
Привет! Честно, я не помню(не искал, не знаю, лень, кто укажет-расскажет , спасибо) исследований, что лучше:
10 вьюшек по 100 энтри, или одна на 1000 энтри.
как выглядит функция скорости лукапа от числа энтри в интервалах 10-50-100-1000 тыс энтри.
я исхожу из своего "здравого" смысла, что на каждую вьюшку сервер выделяет память, и чем меньше вьюшек тем серверу легче, да и у клиента "тажафигня". Но , как водится,я могу ошибаться, т.к. лотус-логика и здравый смысл практически никогда не идут в ногу.
Второе это унификация - единственная лукапная вьюшка в любой базе всегда имеет одинаковую архитектуру, пул одинаковых префиксов ключей ( у меня , например это [KEY], [UNID], [REF], [OBJECTTYPE] или что-то подобное), ключи структурны, легко подлежат декомпозиции. как-то так.
|
Разработка notes-приложений / >2 лукапных вьюшек в БД=импотенция программиста
| 09/14/2010 08:56:36 AM |
|
ну, например, у нее взведен "крыжик" уникальности ключей (самонаполняемые словари, например).
Вот ведь, никто не ведется ))
|
|
| Дополнительно |
| Статистика форума |
Именинники |
 |
Новый пользователь: Олег Изосимов
Участников: 246
Тем: 166
Сообщений: 415 |
|
 |
Нет именинников |
|
|
|
| Статистика |
| Самые активные авторы |
Новые пользователи |
Наиболее просматриваемы темы |
|
|
|
|
|
|