[Разработка, нужны советы] Компонент для УО (УК и тсж) - страница 2 - Расширения форумчан

Внимательно посмотри сам и поймешь, что усложняешь компонент. Своди всё к 5 таблицам, город и адрес это не критические значения.

Согласен что немного громоздкая система таблиц на первый взгляд. Но на самом деле сделана сначала нормализация, а затем денормализация. Т.е. С точки зрения работы с базами данных, там все достаточно логично.
И все нужно. Например в платежке указывается адрес собственника - т.е. таблица адресов нужна. Ну и т.д.

Пока никакой. Этот этап Я еще не делал, поэтому таблицы пока не продумывал.

Основная ошибка, прежде чем разрабатывать что-либо нужно десять раз продумать структуру и взаимодействие различных элементов.

P.S.: Таблица пользователи уже есть в Joomla - это таблица users.

Создай свою таблицу, с расширенным набором полей и привяжи ее к стандартному пользователю, в эту таблицу можешь и адреса записать и номера счетчиков и лицевые счета (у меня это таблица 1).

Но фраза " посчитали счета и записали их в таблицу 4" - предполагает что в разных регионах страны и даже в разных УК "счет может производиться немного по разному".

Нет, везде умножают какое-либо значение на тариф, т.е. если компонент не планирует накрывать целые регионы, а рассчитан на локальное применение, то всё вполне нормально.

А фраза "юзверю вывели платёжку (каждый может отверстать ее по своему)" - предполагает что должна быть возможность верстки. А как указать что в HTML поле таблицы <td>здесь должна быть сумма по горячей воде</td> нужно вставить значение из какой либо таблицы базы данных Joomla ? Вот для этого Я так понимаю и понадобиться плагин.

Зачем плагин, если это всё делается через views.

Например в платежке указывается адрес собственника - т.е. таблица адресов нужна. Ну и т.д.

Адрес собственника брать из профиля пользователя.
Сведи все значения воды/газа/электроэнергии и прочего в единую таблицу, это будет проще - меньше запросов.

1. Пользователи.

Здесь у меня целый ряд связных таблиц. Третья нормальная форма. Т.е. это есть.

2. Тарифы.

Это есть.

3. Последние показания юзверя.

Есть как замечено только по воде.
Действительно можно свести все показания (и по воде и по газу и по электичеству и т.д. и т.п) в одну таблицу.

4. Счета (храним все).
5. Общие показания по дому.

Да эти таблицы нужно добавить. Пока их нет.

Если составить базу всех городов Эрэфии еще реально, то таблицу улиц каждого города - уже не реально, а забивать ее никто не будет, проще всего импортнуть значения адресов из той же 1С или обязать пользователя самостоятельно заполнить поля адреса, проверить то их проще, чем забить в базу.

Здесь у меня целый ряд связных таблиц. Третья нормальная форма. Т.е. это есть.

Вот аналогично сведи в одну таблицу, последующая нагрузка будет меньше.

Зачем у тебя учитывается куча санузлов? Счетчики на воду ставят в одной точке на вход в квартиру и все.

Адрес собственника брать из профиля пользователя.

Я думал над этой темой. Не получается без вмешательства в таблицу users. Нужно заводить в ней доп. поля. Но Я иду по принципу не лезть в движок и не лезть в плане модификации в уже существующие таблицы.

А разбивка таблицы адрес на города и улицы очень удобна.
К примеру у Вас поменялось название улицы. Сейчас при моей организации таблиц, достаточно поменять одно единственное значение в таблице "улицы". А какой геморрой будет если у нас 1000 записей где то в недрах таблицы users, да еще не отдельным полем а единым как поле адрес типа "Москва, ул. Мира, дом 1, кв 1001".

Зачем у тебя учитывается куча санузлов? Счетчики на воду ставят в одной точке на вход в квартиру и все.

Если бы было все так просто
У нас есть квартиры где 6 счетчиков, по два на каждый стояк (отдельно кухня, туалет, ванна).

Ну и так далее.
Например у Вас офис и в нем два счетчика электроэнергии. Можно конечно пойти по пути - нефиг - суммируйте показания и заносите в одну графу. Но конечный потребитель зачастую начинает требовать чтобы именно по каждому счетчику по отдельности велся учет без компромиссов. Ему дескать так удобнее следить за тем где у него расход больше.

Поэтому Я изначально придал некий запас и гибкость компоненту в этом плане.

Я же написал - связать таблицу #__users с #__tsj_account, в которую свести все значения (адрес, счетчики, даты и т.д. и т.п.).

У нас есть квартиры где 6 счетчиков, по два на каждый стояк (отдельно кухня, туалет, ванна).

ОК, тогда всё немного усложнится, но один ёрш проще работать с одной таблицей, одним запросом вытягивая значения по всей квартире.

Для примера посмотри реализацию FLEXIcontent, у тебя получится примерно то же самое, только для профилей пользователя (там для контента).

Я же написал - связать таблицу #__users с #__tsj_account, в которую свести все значения (адрес, счетчики, даты и т.д. и т.п.).

А связь есть. У меня таблица #__tsj_account связана с #__users полем.
Из одной таблицы конечно проще. Спору нет. Но появляется избыточность. И не факт что нагрузка на сервак в случае одной большой таблицы будет меньше чем в случае нескольких маленьких. Количество запросов будет несомненно больше, но объем данный может быть в итоге меньше.
А еще на каком то этапе вступит в игру - время отклика системы. И тут для маленьких таблиц оно будет меньше.

На счет улиц и городов, хорошо, ты берешь id улицы и пишешь в таблицу адреса, а кто будет заполнять таблицу #__tsj_street ? Не усложняй, всё сложное имеет свойство ломаться. По сути - какая разница что выбирать из БД id или значение поля?

Из одной таблицы конечно проще. Спору нет. Но появляется избыточность. И не факт что нагрузка на сервак в случае одной большой таблицы будет меньше чем в случае нескольких маленьких. Количество запросов будет несомненно больше, но объем данный может быть в итоге меньше.
А еще на каком то этапе вступит в игру - время отклика системы. И тут для маленьких таблиц оно будет меньше.

Не вступит, не будет, объем данных достаточно мал, а лишние запросы съедят больше времени, нежели один вытягивающий сразу всю информацию.

На счет улиц и городов, хорошо, ты берешь id улицы и пишешь в таблицу адреса, а кто будет заполнять таблицу #__tsj_street ? Не усложняй, всё сложное имеет свойство ломаться. По сути - какая разница что выбирать из БД id или значение поля?

 
Хорошо что это форум по Joomla. На форуме по SQL и базам данных - порвали бы на 1000 маленьких медвежат это высказывание  

Хорошо что это форум по Joomla. На форуме по SQL и базам данных - порвали бы на 1000 маленьких медвежат это высказывание 

Не порвали бы, в данном случае и id и название улицы - значения, а сделать выборку по введенной улице много проще, чем селектами выбирать улицу, коих может быть 100+

Не вступит, не будет, объем данных достаточно мал, а лишние запросы съедят больше времени, нежели один вытягивающий сразу всю информацию.

Интересный факт. Почему тогда для Битрикс многие хостеры вводят отдельный тариф и даже на отдельный сервак такие сайты выносят? Подозреваю что нагрузка там прет ой-ей-ей какая.

Интересный факт. Почему тогда для Битрикс многие хостеры вводят отдельный тариф и даже на отдельный сервак такие сайты выносят? Подозреваю что нагрузка там прет ой-ей-ей какая.

Это битрикс! J!2.5 может крутиться на 18Мб оперативы, при этом битрикс даже не начнет установку, а если после установки порезать, то один фиг упадет, сам проверял, где-то была холиварная темка, там этот момент расписывал оч. подробно.

Не порвали бы, в данном случае и id и название улицы - значения, а сделать выборку по введенной улице много проще, чем селектами выбирать улицу, коих может быть 100+

А не. Там все намного проще. Нет там нескольких запросов, а только один. Все слепляет по Innerjoin SQL сервак. А запрос всего один проходит.

Это битрикс! ....

Ну не интересовался Я почему Битрикс такой. Ну извините

Объясни мне смысл плодить доп. таблицу адресов? Основной вопрос - зачем? Если есть база, то экспорт будет из нее, а руками набивать - глупо, проще чтобы каждый юзверь сделал это сам.

Блин, нужны программеры! Ребят! Реально нужны советы!

Объясни мне смысл плодить доп. таблицу адресов? Основной вопрос - зачем? Если есть база, то экспорт будет из нее, а руками набивать - глупо, проще чтобы каждый юзверь сделал это сам.

Во-первых достоверность информации. Юзер может вбить в адрес все что угодно, а админу потом проверять это придется. А так у меня реализована функция Импорта и CSV файла. Пожалуйста, делаете файл, а компонент его сам по таблицам рассует как надо. И бухгалтер делает CSV файл один раз в принципе.
Во-вторых сама возможность отдельного редактирования записей (например номера дома или ФИО собственника) - это удобно. Сменился собственник у квартиры - залезли в Админ-панель - поменяли в одном месте руками.

А по отдельной таблице адресов, тут тоже просто. Тут достаточно удобно получается.
Смотрите (ну в общем обычная нормализация).
У Вас за каждой квартирой по бухгалтерии закреплен один лицевой счет. И в этом случае действительно не нужно разделять таблицы адресов и лицевых счетов.
Но что если у Вас на один адрес (одну квартиру) приходиться два-три или 10-ть лицевых счетов. А такое встречается сплошь и рядом, для коммунальных квартир, когда у одной квартиры несколько собственников и они хотят платить раздельно и т.д. Тогда для одной единой таблицы получаем большую избыточность. Например для 10 разных лицевых счетов в таблице будет храниться 10 одинаковых адресов, размер базы сильно увеличивается - результат увеличения времени отклика.

P.S.: На самом деле есть некая золотая середина когда нормализация начинает приводить уже не к упрощению, а к усложнению и к большой нагрузке на сервер. Поэтому если разобраться у меня там не третья нормальная форма и не 4я или 5я, а вторая с половиной.
На самом деле когда Я делал эти таблицы Я консультировался с людьми работающими именно с базами. И они помогли мне выбрать эту самую золотую середину. К слову сказать если например до 4йНФ все бить, то таблиц там получается вместо 4х (город, улица, адрес, лицевой счет) что-то порядка 9ти

Так что мешает импортировать сразу адреса, не давая их редактировать? Изменяемый параметр - жилец.

Но что если у Вас на один адрес (одну квартиру) приходиться два-три или 10-ть лицевых счетов. А такое встречается сплошь и рядом, для коммунальных квартир, когда у одной квартиры несколько собственников и они хотят платить раздельно и т.д. Тогда для одной единой таблицы получаем большую избыточность. Например для 10 разных лицевых счетов в таблице будет храниться 10 одинаковых адресов, размер базы сильно увеличивается - результат увеличения времени отклика.

Здец... Да наплевать юзверям на кол-во собственников! Они хотят получить только инфу о себе, как результат - выборка по пользователю, а не по адресу, адрес вообще нужен только бухам.

Здец... Да наплевать юзверям на кол-во собственников! Они хотят получить только инфу о себе, как результат - выборка по пользователю, а не по адресу, адрес вообще нужен только бухам.

Согласен. Так все и сделано, а то что не сделано планируется так сделать.
Пользователь логиниться. После этого мы знаем кто это, т.е. у нас после этого есть его id из базы users.
Далее выборки идут по этому id с точки зрения тарифов, его счетов и т.п.

А адрес нам нужен только когда он платежку хочет распечатать. Он переходит на страницу нужную и только в этот момент из отдельной таблицы адресов происходит выборка самого адреса и вставляется в платежку. В других случаях (когда он показания по счетчикам вводит, просматривает их и т.п.) адрес не участвует вообще никак. И ни какие Select соответственно на отдельную таблицу адресов не идут.

Ну а отдельно эта таблица сделана для того чтобы снова же не править в случае изменения номера дома или номера офиса (квартиры) в 10ти записях таблицы лицевых счетов, а исправить только в 1м единственном месте, одну единственную запись. Там по таблицам везде получается отношение 1 ко многим.

Хотя вот с номером дома - это как раз то место где сделана денормализация. А по правилам 3НФ еще должна быть отдельная таблица "Номера Домов", "Номера Квартир". Я себе почти перелом мозга получил когда начал разбираться в нюансах оптимизации баз данных  . Там действительно полный ездец.

Пока в таблицах 10-100 записей все обычно идет гладко.
Когда из становится 5000-10000 начинают проявляться всякие нехорошести.
Тут конечно еще все зависит и от программиста, т.е. от того как написать запросы. Можно написать так что и при выборке из таблицы в 1000 записей SQL сервак будет загружен сильно.

Я тут нервно посматриваю иногда на одну соседнюю ветку. Иногда проскакивают сообщения по проблемам при большом количестве >50000 записей в таблицах. Думаю этап оптимизации компонента при работе с большими таблицами - еще предстоит где то в будущем  .

Возьми и распотроши #__content

по адресам - есть справочник всех адресов Российских - называется КЛАДР.
Он правда большой-большой, но там всё есть ))