так вроде делали же в С10, в FAQ - viewtopic.php?f=1&t=3985 там и пример лежит
Генерация описаний файлов/таблиц в multi-dll проекте
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
- ✯ Ветеран ✯
- Сообщения: 1702
- Зарегистрирован: 25 Март 2009, 21:55
- Благодарил (а): 9 раз
- Поблагодарили: 4 раза
Генерация описаний файлов/таблиц в multi-dll проекте
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Такое часто обсуждается на форумах по SQL. Типа взять одну универсальную таблицу и всё туда. С точки зрения самого SQL это допустимо. Я бы сказал - серваку по барабану. Сейчас на этом проекте у меня как раз такое есть (даже смайлик не ставлю). Не три таблицы, правда, а есть таблицы, где хранятся разные сущности. В частности, есть глобальный справочник, где несколько полей и есть поле типа "признак". Повторюсь, что с точки SQL проблем нет. Единственное, целостность порой трудно поддерживать на уровне сервера. А вот с кларионом проблемы. Чтобы отобразить на экране несколько связанных списков по одной скульной таблице (или в одном списке отобразить поля одной таблицы, но связанной с полями этой же), всё равно приходится делать в словаре алиасы. В некоторых случаях (при редактировании в форме) приходится руками текущую запись сохранять в память. В общем, жутко неудобно. Я спросил у создателей - зачем так сделано? Оказывается, им прочитали некий курс по работе с Оракулом. На мой взгляд это какие-то вредители читают. Ещё много чего вдолбили в башку на мой взгляд неправильного. Например, "чем больше индексов, тем медленнее работает сервер". Откуда это? Да, вставка новой записи будет на 0.000001 мс дольше. Зато отбор по индексу на шесть порядков быстрей.Игорь Столяров писал(а): ↑24 Август 2018, 12:49 Я лет десять назад проходил собеседование в одну софтверную фирму, так у них торговая программа была на 3-х таблицах в SQL:
1. Настройки и юзеры;
2. Товары и контрагенты (!!!) - в ней же классификаторы ассортимента, единицы измерения, банки контрагентов и т.д.
3. Документы (вообще все, включая содержание накладных, кассу, выписки из банка и т.д.).
We are hard at work… for you.
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Про индексы - это во всех учебниках по скулю пишут. Считается, что надо прописывать только констрейны для поддержания целостности. Остальные индексы либо скуль создаст автоматически на основании собранной статистики, либо это должен делать администратор базы данных. В некоторых случаях небольших таблиц поиск полным перебором записей в памяти может быть быстрее, чем чтение по индексу. Так как при чтении по индексу вначале надо прочитать этот самый индекс, а потом по нему уже сами записи из базы данных.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7373
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 13 раз
- Поблагодарили: 48 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Кстати, действительно, с точки зрения тех. поддержки - это потрясающе удобно.
Иногда звонят и спрашивают "У нас выключали свет, теперь ошибка открытия файла mm1234.tps, что в нём ?"
Лезишь в словарь, ищешь, смотришь, думаешь ... А так сразу готов ответ: "Ребята, у Вас гавкнулось ВСЁ !"
За теми кто отстал - не возвращаться. (С) Кодекс
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1376
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 7 раз
- Поблагодарили: 1 раз
- Контактная информация:
Генерация описаний файлов/таблиц в multi-dll проекте
Тут должна быть оговорка - при использовании штатных броузов. А если, как у нас, написаны свои на основе ДинаЛиб и хранимок, то можно как угодно
Генерация описаний файлов/таблиц в multi-dll проекте
В одну таблицу можно запихать вагон и маленькую тележку, возможно, что и не маленькую, различных структур.
Имею печальный опыт использования такой таблицы.
Это создает кучу проблем
1. Усложняет понимание структур данных
2. Проблемы с созданием индексов, констрейтов и релэйшенов.
3. Если структуры большие, то проблемы с производительностью.
Как правило, такие структуры используются для создания всевозможных справочников
Есть один плюс от использования такой таблицы.
Можно достаточно быстро добавить несложный справочник.
Но я бы не рекомендовал увлекаться этим и тем более использовать для справочников, которые содержат много записей (сотни, тысячи и более). А использование для справочников содержащих несколько записей или несколько десятков записей вполне оправдано.
Если у вас есть несколько десятков или может быть даже несколько сотен таких справочников, то вполне можно использовать.
Имею печальный опыт использования такой таблицы.
Это создает кучу проблем
1. Усложняет понимание структур данных
2. Проблемы с созданием индексов, констрейтов и релэйшенов.
3. Если структуры большие, то проблемы с производительностью.
Как правило, такие структуры используются для создания всевозможных справочников
Есть один плюс от использования такой таблицы.
Можно достаточно быстро добавить несложный справочник.
Но я бы не рекомендовал увлекаться этим и тем более использовать для справочников, которые содержат много записей (сотни, тысячи и более). А использование для справочников содержащих несколько записей или несколько десятков записей вполне оправдано.
Если у вас есть несколько десятков или может быть даже несколько сотен таких справочников, то вполне можно использовать.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7373
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 13 раз
- Поблагодарили: 48 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Вопрос сводится к уровню изоляции приложения от БД.
Теория говорит, что чем уровень изоляции выше - тем лучше.
В идеале приложение вообще не должно зависеть от структуры и организации данных.
Например делаем различные запросы через REST API - получаем данные, используем.
Во скольких таблицах они хранятся на сервере ? Какие между таблицами связи ?
Какие там индексы ? Какая там БД и есть ли она вообще ? Неизвестно ...
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4615
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 6 раз
- Поблагодарили: 37 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Это справедливо, если база данных живет своей отдельной жизнью. Если база данных встроенная и с ней работает только наше приложение (или все через наше приложение), то теория несколько другая...
C6/C11, ШВС, tps/btrieve.
Генерация описаний файлов/таблиц в multi-dll проекте
Уровень изоляции тут не причем. Он и так достаточный.Игорь Столяров писал(а): ↑26 Август 2018, 16:19Вопрос сводится к уровню изоляции приложения от БД.
Теория говорит, что чем уровень изоляции выше - тем лучше.
Доступ идет через View, поэтому даже программист "не знает", где лежат реальные данные, как называются реальные поля и т.д.
Но это не решает ни одной проблемы.
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Если нужно только посмотреть базу или сделать аналитику, то View, хранимки и ещё много чего подойдёт. А редактировать как? "Ручными" запросами?
We are hard at work… for you.
Генерация описаний файлов/таблиц в multi-dll проекте
Естественно. А что есть другой вариант?
-
- ✯ Ветеран ✯
- Сообщения: 4983
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 20 раз
Генерация описаний файлов/таблиц в multi-dll проекте
Например, стандартные классы и шаблоны. Но тогда в словаре должны быть описаны реальные таблицы, а не вьюхи. Вьюхи описывайте, никто не против, но их редактирование под вопросом. Вернее, всё зависит от реализации сервака. Firebird, например, позволяет редактировать таблицу через вьюху, но при этом на вьюху накладываются ограничения.
We are hard at work… for you.